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This  report  describes  a concept  for  providing  enhanced  terminal  information 
services  (ETIS)  to  aircraft  utilizing  the  ground-air-ground  data  link  capability  of 
the  Discrete  Address  Beacon  System  (DABS).  ETIS  is  envisioned  as  an  eventual  re- 
placement for,  and  significant  improvement  to  the  Automated  Terminal  Information 
Services  (ATIS)  in  use  today. 

The  initial  step  in  developing  the  concept  is  the  establishment  of  requirements 
for  an  ETIS  system.  This  is  followed  by  a determination  of  the  information  and  data 
to  be  provided  to  the  aircraft  over  the  data  link,  and  the  probable  sources  of  that 
data.  An  assumption  is  made  that  the  availability  of  automated  weather  sensor  sys- 
tems of  some  form  will  coincide  with  implementation  of  ETIS.  A detailed  functional 
description  of  the  system  is  then  given,  including  system  configuration,  interfaces 
with  other  ATC  automation  systems,  and  hardware  and  software  both  at  the  airport  and 
at  the  controlling  ATC  facility.  Also  discussed  are  message  content  and  formats, 
controller  and  pilot  display  design  considerations,  criteria  for  dispatch  of  ETIS 
messages,  and  a number  of  operational  considerations.  The  report  concludes  with 
several  typical  flight  scenarios  representative  of  different  levels  of  aircraft, 
avionics,  and  pilot  capabilities  in  an  air  traffic  control  environment  where  ETIS 
is  implemented. 

The  report  clearly  establishes  the  feasibility  of  the  ETIS  system  concept,  and 
provides  an  overall  approach  from  which  a detailed  design  of  the  ETIS  system 
elements  can  be  performed. 


17.  W«rS« 

Comnunications , Digital  Data 

DABS  (Discrete  Address  Beacon  System) 

Data  Link,  DABS 

ATIS  (Automated  Terminal  Information  Services) 
Weather  Observation  Systems,  Automated 

Air  Traffic  Control 

10.  DUHrlbwtlM  lf»— nt 

DOCUMENT  IS  AVAILABLE  TO  THE  PUBLIC 

THROUGH  THE  NATIONAL  TECHNICAL 

INFORMATION  SERVICE,  SPRINGFIELD. 

VIRGINIA  23161 

If.  S#CMH»y  Cl— tlV.  (•!  <!»<• 

JO.  WtwHhr  <•!  tMt  ^•§•1 

JIa  N». 

32.  Rric« 

y 

Unclassified 

Unclassified 

92 

.. 

Farm  DOT  F 1700.7  (t-7» 


RapiadiMNM)  af  caistfd  pag*  SMlIiaritad 


7 o 0 y, 


0 7 O 1 

. i V.  - > 


4 


PREFACE 


As  part  of  its  continuing  effort  to  upgrade  and  improve  the  air 
traffic  control  system,  the  Federal  Aviation  Administration  cur- 
rently has  underway  a program  to  develop,  evaluate,  and  demonstrate 
the  benefits  of  using  the  Discrete  Address  Beacon  System  (DABS) 
digital  data  link  for  transmitting  air-ground-air  messages.  In 
support  of  this  program,  the  Transportation  Systems  Center  has 
developed  a concept  for  providing  enhanced  terminal  information 
services  (ETIS)  to  aircraft  utilizing  the  DABS  digital  data  link. 

The  report  presented  herein  was  prepared  by  the  Office  of  Air 
and  Marine  Systems  of  the  Transportation  Systems  Center  under  the 
sponsorship  of  the  Systems  Research  and  Development  Service  of  the 
FAA.  It  is  one  of  the  tasks  under  project  FA962  entitled  "DABS 
Data  Link,"  and  presents  a detailed  description  of  the  proposed 
concept  for  an  ETIS  system.  The  report  includes  system  require- 
ments, system  configuration  and  functional  description,  message 
contents  and  formats,  avionics  and  controller  display  design  con- 
siderations, system  inputs  and  interfaces,  and  typical  flight 
scenarios . 


The  work  reported  herein  was  completed  under  the  direction  of 
Mr.  John  Bisaga,  Chief  of  the  Systems  Branch,  Communications 
Division,  Systems  Research  and  Development  Service  of  the  FAA,  and 
Mr.  Joseph  Gutwein,  Project  Manager  and  Chief  of  the  Communications 
Branch  at  TSC.  Recognition  for  their  contributions  and  assistance 
to  the  study  effort  is  also  given  to  David  Spokely,  Manuel  Gonzalez, 
Frederic  Pickett  and  Ronnie  Jones  of  the  FAA,  Joseph  Golab  (Project 
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1.  INTRODUCTION 

The  FAA  ci rrently  has  underway  an  R5D  program  with  the  objec- 
tive to  develop,  evaluate,  and  demonstrate  the  benefits  and  methods 
of  using  the  Discrete  Address  Beacon  System  (DABS)  digital  data 
link  capability  to  provide  two-way  air-ground  communication  of 
a variety  of  aviation  related  messages.  Three  categories  of 
services  are  envisioned  under  the  DABS  Data  Link  Applications 
Program,  viz.,  Air  Traffic  Control  (ATC)  automation,  weather 
delivery,  and  terminal  information.  Within  each  of  these  service 
categories  is  a set  of  messages  and  associated  procedures,  data 
sources,  displays,  etc.,  which  effect  the  communication  of  in- 
formation over  the  link,  and  which  are  evolutionary  in  nature, 
expanding  as  the  levels  of  automation  and  services  available  per- 
mit. While  the  various  services  must  be  compatible  with  DABS, 

DABS  avionics,  the  ATC  system,  and  each  other,  it  is  helpful  in 
their  initial  definition  and  design  to  consider  them  individually. 

This  document  addresses  the  terminal  information  category  of 
services,  and  specifically , it  describes  a concept  for  providing 
these  services  utilizing  the  DABS  data  link.  The  concept  is 
referred  to  as  Enhanced  Terminal  Information  Services  (ETIS) , and 
is  defined  as  a flight  advisory  service  which  provides  information 
to  the  pilot  to  assist  him  in  conducting  a safe  approach  to  or 
departure  from  an  airport.  It  includes  as  a subset  all  informa- 
tion currently  provided  by  the  Automated  Terminal  Information 
Service  (ATIS) , plus  other  data  such  as  wind  shear  alerts  which 
pertain  to  the  airport  of  interest.  ETIS  will  not  include  routine 
weather  (weather  delivery  category)  and  ATC  communications  (ATC 
^ automation  category) . 

J 

I 1.1  BACKGROUND 

I A pilot,  in  order  to  safely  land  at  or  depart  from  an  airport, 

I . needs  certain  information  to  assist  him  in  planning  and  carrying 

f 

I out  the  arrival  or  departure.  This  information  includes  such 

i things  as  local  weather  conditions,  altimeter  setting,  runway(s) 
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and  approach  in  use,  and  advisories  regarding  the  particular  airport 
of  interest.  It  is  also  beneficial  to  alert  the  pilot  on  a real 
time  basis  to  any  changes  which  may  affect  the  critical  phases  of 
his  flight.  Examples  are  changes  in  runway  visual  range  (RVR),  the 
approach  of  a thunderstorm,  or  detection  of  wind  shear  conditions. 
The  information  he  requires  is  also  a function  of  what  stage  of 
the  approach  (or  departure)  the  aircraft  is  in.  Runway  and  ap- 
proach in  use  are  needed  early  in  order  to  review  the  appropriate 
approach  procedures,  while  wind  is  most  useful  on  final  approach. 

1.1.1  The  System  Today 

In  today's  system,  the  pilot  obtains  the  needed  terminal  in- 
formation in  one  of  several  ways.  For  an  IFR  approach  to  a remote, 
uncontrolled  airport,  ATC  personnel  give  him  weather,  altimeter 
setting,  etc.,  at  the  closest  reporting  point,  and  the  pilot 
chooses  ';he  type  of  approach  he  wishes  to  fly  (if  more  than  one 
are  available).  ATC  personnel  may  be  able  to  obtain  the  active 
runway  and  local  wind  conditions  from  the  airport  operator  over  a 
land  line,  or  the  pilot  may  be  able  to  obtain  this  information 
over  the  VHF  unicorn  channel  if  there  are  personnel  on  duty  at  the 
airport . 

At  most  controlled  airports,  the  terminal  information  is 
given  to  the  pilot  by  ATC  personnel,  either  the  local  controller 
or  the  approach  controller,  over  the  normal  VHF  communication 
channels.  At  the  busier  airports,  a system  known  as  Automated 
Terminal  Information  Service  (ATIS)  provides  the  needed  information 
to  the  pilot  via  a recorded  message  without  controller  intervention. 
The  ATIS  is  normally  provided  over  a local  or  nearby  VOR  frequency 
on  a continuous  basis.  Prior  to  being  handed  off  to  the  approach 
controller,  or  when  in  range  of  the  appropriate  VOR,  the  pilot 
tunes  his  VOR  receiver  to  the  proper  channel  and  listens  to  the 
ATIS  message.  He  informs  the  approach  controller  upon  initial 
contact  that  he  has  received  the  ATIS,  including  its  alpha 
identifier.  The  alpha  identifier  is  appended  to  the  ATIS  broad- 
cast each  time  it  is  updated  or  changed  by  the  ATC  personnel  to 
insure  that  the  most  recent  version  has  been  obtained  by  the  pilot. 
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The  update  rate  is  normally  about  once  every  hour  when  revised 
weather  observations  are  received,  or  upon  significant  change  in 
weather  or  other  data  (active  runway,  etc.)*  Table  1-1  shows  the 
information  included  in  a standard  ATIS  broadcast. 

ATIS  serves  an  important  function  in  the  ATC  system  of  today, 
and  significantly  reduces  controller  workload  and  communication 
channel  loading.  But  it  has  a number  of  limitations  and  shortcom- 
ings, some  of  which  are: 

1.  A human  operator  (controller  or  flight  service  specialist) 
must  make  the  ATIS  recording  and  update  it  periodically 
from  observations  obtained  from  instruments.  The  potential 
for  error  is  significant  and  the  recording  may  not  be 
current  for  some  items  if  operator  workload  is  high. 

2.  The  ATIS  is  available  locally  only  when  the  aircraft  is 
within  line  of  sight  of  the  broadcasting  transmitter. 

3.  Tape  recording  equipment  in  use  is  prone  to  failure  and  is 
a maintenance  problem. 

4.  Often  the  ATIS  broadcast  is  of  poor  intelligibility  due 
to  equipment,  controller  recording  technique,  propagation 
effects,  or  a combination  of  these.  Misinterpretation  of 
the  information,  or  the  need  to  ask  ATC  to  clarify  the 
conditions  over  the  normal  voice  link  is  the  result. 

5.  Real  time  updating  of  critical  information  is  not  possible 
and  must  be  done  manually  by  the  controller  over  the  voice 
link.  RVR,  for  example,  must  be  monitored  by  the 
controller  by  observing  instruments  and  changes  voiced  to 
the  pilot  during  his  approach  as  required. 

6.  The  pilot  must  copy  the  ATIS  information  by  hand  if  he 
wishes  to  refer  to  it  later  in  the  flight,  or  trust 
his  memory. 

7.  The  design  of  the  ATIS  system  of  today  does  not  allow  it 
to  take  advantage  of  advances  and  improvements  in  auto- 
mation of  the  ATC  and  weather  reporting  systems,  and  in- 
creasing levels  of  avionics  capability. 
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TABLE  1-1.  AT IS  BROADCAST  CONTENTS 


i 

I 

j 1.  Airport  identification 

I 

i 2.  Sky  condition  below  10,000  feet;  visibility  if  less  than  7 

j 

miles,  obstructions  to  vision,  wind  direction  (magnetic), 
wind  speed  (knots),  other  weather  remarks. 

3.  Temperature  and  dewpoint  (optional  but  normally  given) 

4.  Altimeter  setting  (optional  but  normally  given) 

5.  Instrument  approach  in  use,  or  vector  to  be  provided 

6.  Landing  runway (s) 

7.  Takeoff  runway (s) 

8.  NOTAMS  and  Airman's  Advisories 

9.  "Check  Density  Altitude"  message  if  temperature  is  85°F  or 
more  and  tower  altitude  2000  feet  or  more 

10.  Other  pertinent  information 

11.  Phonetic  alphabet  code  of  the  message,  and  instructions  to 


pilot  to  acknowledge  receipt  by  informing  controller  on 
initial  contact 


1.1.2  ETIS 


With  the  implementation  of  DABS  and  its  inherent  data  link 
capability,  most  of  the  shortcomings  of  today's  AXIS  can  be  elimin- 
ated or  at  least  decreased,  plus  additional  services  and  features 
added  which  are  of  significant  potential  benefit  to  the  pilot  and 
the  ATC  system.  Some  of  the  characteristics  which  may  be  included 
in  the  ETIS  system  are: 

1.  Automatic,  real  time  reporting  of  terminal  conditions 
using  automated  sensors  with  no  human  operator  inter- 
vention required  (except  for  NOTAMS , etc.). 

2.  Automatic  transmissions  of  significant  changes  in  informa- 
tion and  of  alerts  which  may  be  of  importance  to  the 
pilot,  such  as  detection  of  a wind  shear. 

3.  Ability  to  tailor  the  information  provided  to  the  phase  of 
flight,  sending  only  the  information  needed  by  the  pilot 
at  that  time. 

4.  Availability  of  ETIS  wherever  DABS  coverage  is  present, 
permitting  the  pilot  to  obtain  the  information  in  suf- 
ficient time  to  plan  his  approach  properly. 

5.  Capability  for  hard  copy  of  the  data  in  the  cockpit. 

6.  Virtual  elimination  of  errors  and  loss  of  intelligibility 
through  extensive  automatic  digital  error  checking,  fault 
sensing,  and  clear,  unambiguous  visual  (or  synthetic 
voice)  displays. 

7.  Potential  to  expand  ETIS  availability  to  airports  not  cur- 
rently equipped  with  AXIS  without  adding  ground  personnel. 

8.  Total  compatibility  with  ATC  system  automation  and  ability 
to  take  advantage  of  growth  and  improvements  in  this  area. 

ETIS  is  considered  as  a high  priority  candidate  for  inclusion 
in  the  early  stages  of  the  evolutionary  implementation  of  DABS 
data  link  services.  This  document  describes  a concept  for  the  de- 
sign of  an  ETIS  system  for  the  mid  to  la*e  1980's  time  frame,  when 
it  is  expected  that  initial  implementation  of  DABS  will  take  place. 
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While  aimed  for  this  time  period,  the  design  is  intended  to  be 
compatible  with  future  ATC  system  enhancements  and  technology 
advances  for  the  1990 's,  and  to  allow  for  improvements  and  the 
addition  of  services  and  features  as  they  become  available. 

1.2  PURPOSE 

The  purpose  of  this  report  is  to  present  the  ETIS  concept  in 
sufficient  detail  to  provide  a thorough  understanding  of  its 
functions  and  operation,  and  to  identify  wherever  possible  those 
areas  and  details  of  the  design  which  are  in  need  of  further  study. 
It  is  hoped  that  this  document  will  stimulate  a continuing 
dialogue  among  the  designers,  users,  and  operators  of  the  system, 
recognizing  that  the  concept  represents  judgments  and  anticipation 
of  what  the  government  envisions  as  a useful  service. 
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2.  REQUIREMENTS 


A set  of  system 
is  described  below. 
ETIS  concept  in  that 
is  structured.  Some 
achieved  than  others 
considered  to  be  of 
in  the  design  of  the 
do  so . 


requirements  has  been  established  for  ETIS  and 
The  requirements  are  an  important  part  of  the 
they  provide  a framework  upon  which  the  design 
requirements  are  more  easily  defined  and 
and  some  are  not  fully  resolved.  All  are 
sufficient  importance  to  be  taken  into  account 
ETIS  concept,  and  an  attempt  has  been  made  to 


2.1  SYSTEM  ENMANCr.MENT 

ETIS  must  have  the  potential  of  contributing  to  the  safety, 
capacity,  and/or  productivity  of  the  ATC  system  from  both  the 
users'  and  operators'  perspectives.  It  must  also  be  designed  and 
implemented  in  such  a way  that  improvements  in  one  aspect  of  the 
system  do  not  result  in  a negative  effect  in  another.  More 
specifically,  ETIS  must  offer  some  significant,  observable  improve- 
ment over  the  ATIS  system  of  today  to  warrant  its  further  design, 
evaluation,  and  implementation.  The  shortcomings  of  ATIS  listed 
earlier  are  all  areas  where  improvements  are  desirable  and  in  which 
a properly  designed  ETIS  can  be  beneficial.  Improvements  in  all  or 
some  of  the  following  are  required: 

1.  currency  of  data 

2.  accuracy  of  data 

3.  "intelligibility"  of  data 

4.  availability 

5.  reliability 

6.  human  operator  involvement 

7.  timely  dispatch  of  alerts 

8.  compatibility  with  future  ATC  system  enhancements. 
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No  attempt  has  been  made  to  prioritize  the  above  for  a number 
of  reasons,  the  most  important  being  that  priorities  depend  upon 
the  individual  viewpoint  (pilot  or  controller).  However,  with  few, 
if  any,  exceptions,  improvement  to  any  one  of  the  above  is  suf- 
ficient justification  for  further  effort  in  the  development  of 
ETIS. 

2.2  PILOT  AND  CONTROLLER  WORKLOAD 

It  is  desirable  that  ETIS  result  in  a net  reduction  in  pilot 
and  controller  workload.  While  it  is  clear  that  such  a reduction 
would  be  beneficial  to  the  system  and  welcomed  by  all  concerned, 
there  are  other  improvements  listed  earlier  which  are  also  attrac- 
tive and  sufficient  to  warrant  implementation  of  ETIS  if  they  can 
be  demonstrated.  The  most  important  factor  is,  however,  that 
regardless  of  what  other  improvements  and  benefits  are  achieved, 
they  must  not  result  in  any  increase  in  pilot  or  controller  work- 
load. There  is  no  shortcoming  in  today's  system  of  disseminating 
terminal  information  that  is  so  severe  as  to  justify  an  ETIS  con- 
cept that  adds  to  the  user  or  operator's  net  workload. 

The  term  "net  workload"  is  important  to  understand  in  this 
context.  It  is  conceivable  that  an  ETIS  system  would  add  new 
tasks  or  procedures  that  the  pilot  or  controller  does  not  have 
today,  while  eliminating  or  reducing  others.  The  net  change  in 
resulting  workload  in  each  case  must  be  zero  or  negative  for  ETIS 
to  be  acceptable.  Analysis  and  measurement  of  this  workload  change, 
however,  are  not  straightforward  and  may  be  an  area  requiring 
considerable  evaluation  before  finalizing  the  ETIS  design.  Work- 
load variations  from  the  perspective  of  the  user  are  not  always 
consistent  with  that  from  the  perspective  of  an  observer,  or  even 
with  that  of  another  user,  which  makes  evaluation  difficult. 

2.3  ATC  SYSTEM  COMPATIBILITY 

The  ETIS  concept  must  be  compatible  with  the  ATC  system  of 
the  mid  to  late  1980's  and  beyond.  There  are  three  distinct 
aspects  to  compatibility.  First,  ETIS  must  be  designed  to  function 
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with  the  DABS  data  link,  technically  and  operationally.  Its  data 
formats,  message  update  rates,  message  lengths,  etc.  must  conform 
to  DABS  provisions  and  avionics  designs,  and  be  consistent  with 
other  data  link  services.  Similarly,  its  interfaces  with  the  rest 
of  the  ATC  system  for  message  coordination,  extraction  of  data, 
etc.  must  be  properly  designed. 

Second,  ETIS  must  be  suitable  for  implementation  in  the  mid 
to  late  1980's  when  DABS  is  expected  to  be  first  deployed.  It 
must  operate  in  an  environment  which  is  mixed  DABS  and  ATCRBS,  as 
well  as  an  environment  in  which  some  aircraft  are  equipped  with 
neither.  This  initial  implementation  must  utilize  technologies 
available  now,  or  within  the  next  two  to  three  years  at  most,  to 
insure  sufficient  time  for  development,  procurement,  and  test  of 
hardware  and  software.  If  ETIS  eliminates  the  conventional  ATIS 
broadcast  at  some  locations,  it  should  have  the  capability  of  pro- 
viding a similar  service  to  non-DABS-equipped  aircraft  (e.g. 
digitized  voice  broadcast  over  VHP). 

Finally,  ETIS  must  be  designed  in  such  a way  that  it  will  be 
capable  of  taking  full  advantage  of  advances  in  avionics  tech- 
nology and  of  improvements  in  the  ATC  system,  particularly  as 
increased  levels  of  automation  are  achieved.  An  example  is 
runway  assignment.  Studies  are  underway  to  develop  software  to 
automate  the  assignment  of  runways  at  larger  terminals.  ETIS  must 
be  designed  so  that  this  information  can  be  extracted  and  dis- 
patched to  the  pilot  at  the  proper  time,^  should  this  capability 
be  achieved.  It  should  also  allow  for  the  use  of  this  data  to 
further  tailor  the  information  sent  to  the  pilot,  such  as  RVR  when 
more  than  one  approach  is  in  use.  When  low  cost  remote  weather 
sensing  systems  are  available,  ETIS  software  should  allow  for  the 
addition  of  uncontrolled  airports  to  those  which  have  ETIS 
capability.  Indeed,  any  airport  with  an  instrument  approach  pro- 
cedure and  within  coverage  of  a DABS  sensor  is  an  eventual  ETIS 
candidate . 


^Strictly  speaking,  this  is  an  ATC  function,  not  an  advisory 
service . 
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Simply  stated,  ETIS  must  work  in  the  early  DABS  environment 
with  the  ATC  system  as  it  exists  then,  and  be  designed  to  grow 
in  capability  and  services  offered  consistent  with  the  growth  in 
ATC  system  automation  and  advances  in  avionics  technology. 

2.4  USER  COMPATIBILITY 

Aviation  today  is  comprised  of  a broad  variety  of  pilots  and 
aircraft  representing  numerous  levels  of  sophistication,  capability, 
and  needs.  They  all  utilize  essentially  the  same  airspace,  and 
for  the  most  part,  fly  into  and  out  of  the  same  airports.  ETIS 
must  therefore  be  designed  with  the  single-engine  aircraft,  VFR 
pilot  in  mind,  as  well  as  the  commercial  airline  pilot  flying  a , 

747.  And  it  must  consider  all  levels  of  sophistication  in  between. 

Only  in  this  way  can  it  serve  a large  segment  of  the  user  popula- 
tion. 

For  the  purpose  of  developing  an  ETIS  concept,  this  require- 
ment comes  down  to  three  primary  factors:  avionics  cost  vs. 
capability,  IFR  vs  VFR  operations,  and  single  pilot  vs.  multi- 
crew cockpits.  Capability  for  eventual  implementation  at  smaller 
airports  not  currently  served  by  ATIS  could  also  be  considered 
under  this  requirement. 

The  ETIS  concept  should  be  compatible  with  very  elementary 
DABS  data  link  display  devices  such  as  might  be  found  on  a small 
single-engine  aircraft.  While  the  level  of  service  provided  and 
ease  of  operation  may  not  be  the  same  as  for  a more  expensive, 
airline  installation,  ETIS  services  should  be  available  to  a 
"minimally  equipped"  user.  (Minimally  equipped  has  not  been 
defined,  and  the  concept  will  of  necessity  make  certain  assump- 
tions in  this  regard.)  Furthermore,  ETIS  should  not  remove  any 
service  available  today  without  replacing  it  with  an  equivalent 
or  better  substitute.  Non-DABS-equipped  aircraft  must  still  be 
able  to  obtain  ATIS  information. 

ETIS  should  provide  services  to  VFR  aircraft  not  on  a flight 
plan  which  are  arriving  at  or  departing  from  an  ETIS  terminal. 

Provisions  should  be  made  in  the  design  to  obtain  any  required 
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information  regarding  the  flight  in  order  that  ETIS  may  be  pro- 
vided over  the  data  link  if  the  aircraft  is  DABS  equipped.  Again, 
the  level  of  service  and  ease  of  use  in  this  case  may  not  be  as 
great  as  for  an  IFR  flight. 

Finally,  ETIS  information  must  be  presented  in  such  a way 
that  it  can  be  readily  understood  and  absorbed  by  the  single  pilot 
crew,  as  well  as  the  multi-crew  situation.  As  an  example,  the  use 
of  clear  textual  formats  with  easily  understood  abbreviations  is 
important.  Message  timing  and  procedures  for  acknowledgement  of 
messages  or  message  segments  must  take  into  account  the  crew 
configuration  and  task  loading  during  the  busy  terminal  area  phase 
of  flight. 

2.5  COST  EFFECTIVENESS 

The  cost/effectiveness,  measured  in  terms  of  a cost/benefit 
ratio,  is  a primary  consideration  in  the  design  of  the  ETIS  sys- 
tem, just  as  it  is  for  any  ATC  system  improvement.  Cost/effective- 
ness must  be  taken  into  account  for  both  the  system  operator  (FAA) 
and  for  the  various  classes  of  users. 

No  attempt  will  be  made  at  this  stage  of  the  concept  develop- 
ment to  perform  cost/benefit  analyses.  This  exercise  actually 
must  be  part  of  an  overall  cost/benefit  study  of  DABS  data  link 
as  a whole,  and  would  be  incomplete  if  attempted  for  just  the 
ETIS  system  alone.  However,  attention  must  be  given  during  the 
design  of  the  ETIS  concept  to  cost  sensitive  areas  such  as 
complexity,  flexibility,  reliability,  and  technology  trends,  and 
how  they  are  affected  by  the  services  under  consideration  and  the 
various  design  tradeoffs. 


3.  CONCEPT  DESCRIPTION 


The  ETIS  concept  described  in  this  section  is  based  upon  the 
requirements  of  Section  2.  The  problem  is  approached  from  the 
viewpoint  of  determining  what  information  of  an  advisory  nature 
(other  than  traffic)  does  the  pilot  need  in  order  to  conduct  a 
safe  approach  or  departure,  when  and  how  should  it  be  provided  to 
him,  and  how  can  the  DABS  data  link  best  be  used  to  perform  this 
function.  To  answer  these  questions,  others  must  also  be 
addressed:  What  information  should  be  transmitted  automatically 
and  what  should  be  by  pilot  request  only?  When  should  the  pilot 
be  informed  of  changes  in  the  data?  How  often  should  the  data  be 
updated?  What  are  the  sources  of  the  data?  What  is  the  role  of 
the  controller  in  the  ETIS  concept?  Note  that  the  approach  taken 
is  not  to  simply  replace  ATIS  with  a system  that  utilizes  the  DABS 
data  link. 

All  of  these  questions,  and  others,  are  addressed  to  the 
extent  possible  in  the  concept  design  presented  herein.  In  so 
doing,  a number  of  issues  are  raised  for  which  no  clear  answer  can 
be  determined.  In  such  cases,  an  attempt  is  made  to  clearly 
identify  the  issue  and  alternative  solutions  or  designs,  and 
recommend  one  or  more  alternatives  as  being  perhaps  the  most 
desirable.  To  finalize  the  design  in  these  areas,  the  results  of 
other  planned  and  ongoing  activities,  such  as  pilot  and  controller 
surveys,  demonstration  and  evaluation  flight  tests,  and  cost/ 
benefit  studies  will  be  necessary. 

3.1  SUMMARY  OF  ETIS  CONCEPT 

The  ETIS  concept  describes  a means  whereby  various  terminal 
information  services  are  provided  to  pilots  via  the  DABS  data  link 
It  consists  of  the  following  elements: 

1.  A set  of  terminal  information  services  consisting  of 
various  messages  containing  weather  data,  airport 
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status,  alerts,  and  other  advisories  of  benefit  to  a 
pilot,  and  dispatched  in  accordance  with  the  require- 
ments of  the  different  phases  of  flight  in  the  terminal 
area . 

2.  Hardware  at  airports  to  collect  and  input  ETIS  data, 
including  interfaces  with  weather  sensor  systems,  displays, 
input  terminals  and  associated  processing  equipment,  and 
communication  links. 

3.  Software  resident  in  the  DABS  data  link  applications 
processor  (AP)  at  the  controlling  ATC  facility  to  generate 
messages,  process  input  data,  handle  requests,  etc.  This 
processor  also  performs  functions  related  to  other  data 
link  applications. 

4.  Avionics,  including  displays,  keyboard  input  devices, 
processors,  etc.  on  board  DABS  equipped  aircraft.  These 
avionics  are  shared  with  other  DABS  surveillance  and  data 
link  applications. 

5.  A set  of  operational  procedures  and  system  design 
characteristics  which  determine  what  information  is 
sent  at  what  time  and  how  the  pilot  and  controller  access 
the  system. 

Figure  3-1  depicts  the  proposed  ETIS  system  in  a typical 
installation.  A local  processor/display  system  (LPDS)  located 
at  the  airport  obtains  local  weather  observations  from  automated 
weather  sensor  systems.  The  controller  or  airport  operator  enters 
certain  additional  information  as  required,  including  runway  and 
approaches  in  use  and  NOTAMS.  The  LPDS  processor  performs  any 
necessary  input  data  processing,  error  checking,  sensor  system 
polling,  etc.,  and  interfaces  with  a modem  that  provides  the  com- 
munication link  with  the  DABS  data  link  applications  processor 
(AP) . The  LPDS  display,  also  installed  at  the  local  airport,  will, 
where  available,  be  the  Terminal  Information  Processing  System 
ij  (TIPS)  display  planned  for  installation  in  many  tower  cabs  during 

the  mid-1980's.  This  display/input  terminal  enables  the  local 
[(  controller  to  access  the  local  ETIS  data  as  well  as  provide  any 
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necessary  manual  inputs.  Also,  at  most  if  not  all  locations, 
particularly  those  with  ATIS  today,  a digital  voice  system  (DVS) 
is  connected  to  the  LPDS  processor  to  provide  automatic  digitized 
ETIS  voice  broadcasts  over  the  VHP  channel  currently  used  for 
ATIS. 

At  the  controlling  ATC  facility  (which  may  be  co-located  at 
the  airport)  the  ETIS  information  is  inputted  to  the  AP  via  a land 
line  and  modem.  The  AP  may  have  more  than  one  ETIS  input,  depend- 
ing upon  the  number  of  airports  within  coverage  of  the  DABS  sen- 
sor that  have  ETIS  capability.  Software  in  the  AP  controls  the 
communication  link  with  the  LPDS  processor (s)  , polling  it  for 
data  as  required  and  maintaining  a table  of  the  most  current 
information.  At  this  facility,  controller  access  to  the  ETIS 
data  for  each  airport  within  its  jurisdiction  is  provided  by  the 
TIPS  TRACON  Display  Subsystem. 

When  a DABS-equipped  aircraft  which  is  bound  for  a ETIS- 
equipped  airport  reaches  a specified  area  within  the  coverage  of 
the  DABS  sensor  (60  mile  radius)  , the  ETIS  software  in  the  AP 
formats  a message  whose  contents  are  similar  to  ATIS  of  today  and 
dispatches  it  automatically  to  the  aircraft.  As  the  aircraft 
proceeds  into  the  terminal  area,  makes  its  approach,  and  lands, 
pertinent  data  are  automatically  dispatched  to  the  aircraft  by 
the  AP  at  the  appropriate  points  in  the  flight  and  depending 
upon  the  local  conditions.  Such  data  may  include  RVR,  significant 
parameter  changes  such  as  altimeter  setting,  wind  shear  alert, 
etc.  On  a calm,  VFR  day,  it  is  conceivable  that  the  only  ETIS 
message  dispatched  after  the  initial  arrival  message  may  be  wind 
on  final  approach. 

In  addition  to  automatic  dispatch  of  ETIS  messages,  the  pilot 
will  have  the  option  of  requesting  ETIS  information  for  any 
suitably  equipped  airport  at  any  point  in  his  flight,  as  long  as 
the  aircraft  is  within  coverage  of  a DABS  sensor.  Furthermore, 
any  aircraft  whose  destination  is  unknown  to  the  ground  (VFR 
flight  perhaps)  will  have  to  request  ETIS,  or  a means  provided 
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for  communicating  the  aircraft  destination  to  the  ground  system. 
This  aspect  is  discussed  in  more  detail  later. 

ETIS  messages  will  be  displayed  in  the  cockpit  using  a 
variety  of  data  link  displays  which  depend  upon  the  size  of 
the  aircraft  and  sophistication  of  avionics  tha.  "he  pilot  can 
afford.  Some  minimum  capability  will  be  required  for  the  number 
of  alphanumeric  characters  and/or  storage  registers  of  the  display 
so  that  the  avionics  can  handle,  although  perhaps  net  display  at 
one  time,  an  entire  ETIS  message,  which  includes  airport  advisories 
and  may  be  200  or  more  characters  in  length.  A CRT  or  printer 
type  of  display  provides  the  most  capability  for  long  messages. 
Display  design  will  be  influenced  by  the  other  services  to  be  pro- 
vided by  the  DABS  data  link,  since  it  is  not  likely  that  any  data 
link  service  will  have  a dedicated  display  (except  perhaps  ATARS) . 

The  following  sections  discuss  in  detail  each  aspect  of  the 
ETIS  concept. 

3.2  ETIS  INFORMATION 

Most  of  the  information  to  be  provided  by  ETIS  is  contained 
in  today's  ATIS  report.  The  primary  difference  between  the  two 
is  that  with  ETIS  the  information  is  continually  updated,  critical 
data  or  changes  in  data  are  automatically  sent,  and  messages  are 
dispatched  at  the  points  in  the  flight  where  they  are  most  needed. 
For  ETIS,  it  is  also  necessary  that  analog  data  be  converted  to  a 
digital  form  to  be  compatible  with  the  DABS  data  link. 

The  two  major  sources  of  information  for  the  ETIS  system  are 
automated  weather  sensors  and  a manual  keyboard  or  terminal.  In 
the  former  category,  several  systems  are  currently  under  develop- 
ment by  the  FAA,  including  Aviation  Automated  Weather  Observation 
System  (AV-AWOS)  and  Automated  Low-Cost  Weather  Observation 
System  (ALWOS) , both  of  which  provide  unmanned,  real-time  report- 
ing of  surface  weather  condtions.  The  ETIS  concept  assumes  the 
existence  of  AV-AWOS,  ALWOS,  and/or  other  similar  automated  weather 
sensor  systems,  and  obtains  most,  if  not  all,  weather  data  inputs 
from  such  a system. 
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It  should  be  emphasized  that  responsibility  for  development 
of  AV-AWOS,  ALWOS,  etc.  lies  with  those  of  the  I-AA  responsible  for 
the  collection  and  dissemination  of  weather  information,  not  with 
the  DABS  data  link  or  ETIS  designers.  ETIS  is  to  be  viewed  as  an 
effective,  efficient  means  of  automatically  disseminating  these 
data.  If  such  automated  weather  observation  capability  is  not 
available  when  DABS  data  link  is  implemented,  some  manual  observa- 
tions for  ETIS  will  be  necessary,  or  ETIS  implementation  must  be 
delayed.  The  important  point  is  that  the  DABS  data  link  program 
will  not  undertake  an  independent  automated  weather  sensor 
system  development  effort. 

The  following  paragraphs  provide  a discussion  of  the  various 
data  items  to  be  included  in  ETIS  and  the  status  of  weather  sensor 
development  necessary  to  provide  each  item  Table  3-1  summarizes 
the  sensor  system  output  parameters  assumed  to  be  available  as 
inputs  to  ETIS,  and  is  based  on  the  current  AV-AWOS  draft  specifica- 
tion^ except  where  another  probable  source  of  data  is  indicated. 
Although  the  sensors  themselves  are  not  the  responsibility  of  the 
data  link  designers,  the  discussion  included  here  is  considered 
important  to  define  completely  the  ETIS  concept  and  the  underlying 
assumptions  behind  it. 

3.2.1  Runway  and  Approach  in  Use 

Runway(s)  and  instrument  appfoach(es]  in  use  are  included  in 
the  initial  ETIS  message,  and  include  both  arrival  and  departure 
runways,  if  different.  This  information  must  be  entered  manually 
with  a keyboard  by  a local  controller,  FSS  specialist,  or  by  the 
airport  operator  at  smaller  fields.  Through  careful  software  de- 
sign and  preformatting,  and,  if  necessary,  by  tailoring  the  soft- 
ware to  the  individual  airport  it  is  expected  that  keying  in  this 
data  will  be  a simple  task,  and  need  only  be  done  when  a change  in 
arrival/departure  configuration  is  made.  It  is  possible  that 


^FAA,  "Specification  for  Aviat ion- Automated  Weather  Observation 
System  (AV-AWOS)  - Draft,"  FAA-ER-450,  December  12,  1978. 
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algorithms  will  be  developed  to  assign  runways  and  approaches  to 
aircraft  automatically  in  the  very  busy  terminal  areas.  This 
software  will  probably  reside  in  ARTS  or  TIPS,  but  would  likely 
be  designed  to  select  a runway  for  an  aircraft  from  the  pre- 
determined approach/departure  configuration.  It  is  this  pre- 
determined configuration  that  would  be  included  in  the  initial  ETIS 
message,  and  would  still  be  a manual  input  s^nce  it  probably  will 
always  require  a decision  by  a human.  However,  the  automatic 
assignment  of  a runway  will  be  used  by  the  ETIS  software  as  an 
enhancement  in  its  delivery  of  some  services.  (See  Section 
3.3. 2.3) . 

3.2.2  Sky  Condition 

Sky  condition  includes  the  height  of  cloud  layers  and  portion 
of  sky  covered.  This  data  will  be  obtained  automatically  from  some 
type  of  ceilometer,  and  should  provide  data  on  at  least  three 
layers  up  to  an  altitude  of  7,000  feet  or  more  above  the  surface. 

It  will  be  included  in  the  initial  ETIS  message,  and  any  significant 
changes  transmitted  to  arriving  aircraft  which  have  received  the 
initial  ETIS  message. 

Some  technology  development  must  take  place  in  this  area  to 
provide  a suitable  sensor.  The  widely  used  rotating  beam  ceilometer 
is  not  an  attractive  candidate.  It  is  designed  for  interpretation 
by  a human  observer,  has  limited  altitude  capability,  and  suffers 
from  high  installation  and  maintenance  costs.  It  has  been  used 
successfully,  however,  in  limited  field  tests  of  AV-AIVOS  by  the  FAA 
and  National  Weather  Service.  Efforts  underway  to  develop  a 
suitable  laser  ceilometer  show  promise  in  meeting  the  height,  cost, 
and  reliability  requirements  of  an  automated  sky  condition  sensor. 
The  ETIS  concept  assumes  the  availability  of  such  a sensor. 

3.2.3  Prevailing  Visibility  and  Precipitation 

Prevailing  visibility  will  be  given  in  miles  and  fractions 
thereof  (if  less  than  2 1/2  miles)  as  a part  of  the  initial  ETIS 
message,  and  if  less  than  2 miles,  at  the  final  approach  fix  of 


non-precision  approaches.  Any  significant  changes  will  also  be  trans- 
mitted to  arriving  aircraft  any  time  after  they  have  received  the 
initial  KTIS  message.  Included  as  part  of  these  messages  will  be 
an  indication  of  the  obstructions  to  visibility,  such  as  rain,  fog, 
etc . 
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another  area  where  some  advances  in  technology 
is  desirable  that  visibility  be  measured  with 
eight  miles.  Transmissometers  are  limited  in 
bly  less  than  this,  require  a large  area  of 
ations,  and  have  high  maintenance  costs.  The 
? used  in  the  AV-AWOS  tests  suffered  from  un- 
values under  certain  conditions.  The  forward 
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that  such  capability  will  exist  in  the  time- 
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Obstruction  to  visibility  is  less  certain  to  achieve  in  an 
automated,  unmanned  fashion.  AV-AWOS  tested  devices  which  pro- 
vided "precipitation  yes/no"  (tipping  bucket  rain  guage)  , "freezing 
rain  yes/no"  (aircraft-type  icing  detector),  and  a momentum  type 
hail  detector.  All  of  these  devices  have  some  problems  which 
render  them  unlikely  as  suitable  weather  sensors.  The  National 
Weather  Service  is  currently  involved  in  a program  to  develop 
laser  technology  to  detect  and  distinguish  between  rain,  snow,  fog, 
drizzle,  and  clear,  with  further  refinements  and  estimation  of 
mixtures  planned.  Lithometeor  detection  is  also  being  studied 
for  classifications  such  as  dust,  haze,  smoke,  etc.  The  latter 
is  not  planned  for  evaluation  until  1982. 

It  is  likely  that  automated  techniques  will  be  available  by 
the  mid-80's  to  provide  at  least  major  classification  of  visibility 
obstructions,  with  improvements  coming  along  as  technology  advances. 
This  will  not  depend  on  ETIS  or  DABS  data  link,  but  is  highly 
beneficial  in  its  own  right  to  provide,  for  example,  weather 
observations  at  remote  uncontrolled  fields  which  have  instrument 
approach  procedures.  The  ETIS  concept  will  assume  the  existence 
of  some  automated  capability,  with  increasing  levels  of  sophistica- 
tion as  time  goes  on. 
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3.2.4  RVJ^  (Runway  Visual  Range) 

RV'R  is  available  directly  from  the  transmissometer-based  RVR 
system  used  today,  with  a straightforward  interface  easily 
implemented.  It  may  also  be  obtained  from  AV-AWOS  if  an  inte^'- 
face  with  the  RVR  system  is  implemented. 

RVR  will  be  provided  in  the  initial  FTIS  message  for  the  run- 
way(s)  in  use  and  at  the  outer  marker,  but  only  if  it  is  less  than 
6000  feet.  Runway  visibility  (RV)  will  be  provided  if  it  is  used 
instead  of  RVR.  Significant  changes  in  RVR  will  also  be  given  any 
time  after  the  initial  ETIS  message  has  been  sent.  Mid-point  and 
roll-out  RVR  will  be  included  in  all  RVR  messages  if  available. 

3.2.5  Winds  and  Wind  Shear  Alert 

Center  field  wind  direction,  velocity,  and  gust  factor  will  be 
given  in  the  initial  ETIS  message,  and  at  or  just  after  the  outer 
marker  or  final  approach  fix.  Anemometers  with  outputs  readily 
interfaced  with  a digital  transmission  system  are  available  to 
provide  this  data. 

It  is  also  proposed  that  sector  or  runway  wind  information  be 
provided  where  available  from  LLWSAS  (Low  Level  Wind  Shear  Alert 
System)  or  other  sensor  systems.  This  information,  for  the  runway 
of  interest,  would  be  transmitted  at  the  outer  marker  or  final 
approach  fix  along  with  center  field  wind  (which  could  also  be 
obtained  from  LLWSAS).  Knowledge  of  the  wind  closer  to  the  final 
approach/touchdown  zone  appears  to  have  value  in  the  conduct  of  a 
safe  approach,  particularly  under  conditions  of  varying  winds, 
frontal  passage,  thunderstorm  activity,  etc.  But  this  point  is 
still  open  for  debate  due  to  the  lack  of  availability  of  sensors 
at  most  airports,  differences  in  their  locations  around  the  air- 
port geometry,  and  the  possibility  of  misinterpretation  of  the 
data.  More  time,  experimental  study,  and  experience  with  instal- 
lations such  as  LLWSAS  are  necessary  in  order  to  get  a better  feel 
for  the  desirability  of  providing  this  data.  The  ETIS  concept 
includes  this  capability  on  the  assumption  that  it  will  prove  to 
be  beneficial  in  some  form,  and  that  subitable  operational 
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procedures  will  be  worked  out.  (The  ETIS  design  must  be  such 
that  questions  of  this  sort,  when  resolved,  can  be  readily  imple- 
mented into  the  system,  or  appropriate  modifications  easily  made.) 

In  any  case,  wind  shear  alerts  will  be  provided  when  detected 
by  the  LLWSAS  equipment  as  soon  as  they  occur,  and  will  be  in- 
cluded in  the  initial  ETIS  message  for  some  period  of  time,  per- 
haps five  minutes,  following  time  of  detection.  Center  field 
wind,  the  sector  or  runway  wind  associated  with  the  shear,  and 
their  vector  difference,  if  the  latter  is  determined  to  be  useful, 
will  be  transmitted  in  the  alert  message.  (See  Sections  3. 3. 2. 2. 7 
and  3. 3. 2. 3. 2 for  further  discussion  of  wind  shear  alert.) 

3.2.6  Temperature  and  Dewpoint 

Temperature  and  Dewpoint  will  be  included  in  the  initial 
message.  Sensors  are  readily  available  for  these  functions, 
either  separately  or  with  combined  capability. 

3.2.7  Altimeter  Setting 

Altimeter  setting  will  be  included  as  part  of  the  initial  ETIS 
message,  and  will  also  be  transmitted  to  all  aircraft  at  every 
incremental  change  of  .01  inches.  Digital  barometers  suitable  for 
this  function  are  readily  available. 

3.2.8  Pressure,  Temperature  and  Thunderstorm  Alerts 

Certain  data  may  be  useful  in  the  terminal  area  to  warn  of 
approaching  thunderstorms  and  gust  fronts.  Various  studies  have 
been  and  are  being  conducted  to  determine  if  information  regarding 
pressure  jumps  and/or  rapid  drops  in  temperature  at  several  points 
around  the  periphery  of  an  airport  might  be  used  to  detect,  track, 
and  predict  the  path  of  thunderstorms.  Other  means  may  be 
developed  for  reliably  detecting  thunderstorm  activity  in  an 
automated  fashion. 

The  ETIS  concept  includes  the  capability  to  send  this  type  of 
data  to  aircraft  in  the  area  when  detected.  While  it  is  difficult 
to  anticipate  at  this  time  what  form  this  data  will  be  in,  it  is 


I safe  to  assume  at  least  the  existence  of  a simple  thunderstorm 
» alert  message,  with  capability  to  add  data  regarding  location, 
r direction  of  travel,  speed,  etc.,  as  this  becomes  available. 


Similar  capability  is  called  for  in  the  current  AV-AWOS  specifica- 
i tion.  It  is  proposed  that,  at  least  for  initial  implementation, 

alerts  based  on  pressure  jumps  and  rapid  drops  in  temperature  be 
^ included.  These  may  prove  to  be  valuable  in  and  of  themselves, 

and  may  be  all  that  is  available  at  the  smaller  airports.  These 
alerts  will  be  generated  by  algorithms  contained  within  AV-AWOS, 

ALWOS,  etc. 

3.2.9  Density  Altitude 

At  those  airports  at  an  altitude  of  2000  feet  or  more,  and 
, when  the  temperature  exceeds  8S°F,  ETIS  software  in  the  AP  will 

calculate  the  density  altitude  and  include  this  data  in  the  in- 
j itial  ETIS  message.  No  additional  input  data  are  required,  and 

the  criteria  for  including  it  or  not  can  be  easily  changed.  The 
• values  selected  above  represent  the  criteria  used  today  to  add 

"Check  Density  Altitude"  to  an  ATIS  broadcast. 

1 . 3.2.10  Airport  Advisories 

1 1 

; Airport  advisories  include  all  airport  status  information, 

special  notices,  advisories,  and  other  terminal  information,  both 
temporary  and  semi-permanent  in  nature,  that  are  necessary  or 
helpful  for  safe  operation  in  the  terminal  area.  Also  included 
is  identification  of  any  SIGMETS  or  AIRMETS  which  are  currently 
in  effect.  (The  text  of  the  SIGMET  or  AIRMET  would  not  be  a part 

of  the  ETIS  message.)  Examples  which  could  be  part  of  an  ETIS  I 

^ message  include  runway  braking  action  reports,  ice  patches,  closed 

I runways  or  taxiways , noise  abatement  procedures,  construction  equip- 

, ment,  out  of  service  nav-aids,  special  instructions  for  VFR  arrivals, 

i 

etc.  The  possibilities  are  numerous  and  vary  greatly  in  length,  li 

frequency  of  use,  criticality,  and  format.  ' 

Most  airport  advisories  must  be  entered  manually  using  the  i 

keyboard  terminal  at  the  airport.  The  wide  variations  in  this  type  - j 
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of  information  result  in  some  manual  typing  by  the  controller 
being  unavoidable.  But  steps  can  be  taken  to  minimize  this 
requirement  through  careful  design  of  the  operating  software.  Once 
an  advisory  or  NOTAM  is  entered,  it  will  be  included  in  all  initial 
ETIS  messages  until  removed  or  changed.  Thus,  semi -permanent 
advisories  such  as  "VFR  arrivals  contact  approach  control  on 
126.6"  are  entered  once  and  no  further  action  is  required.  Data 
which  are  frequently  but  not  always  given,  depending  upon  local 
conditions,  can  be  pre-stored  and  simply  retrieved  by  the  control- 
ler for  inclusion  in  the  ETIS.  (This  operation  would  be  required 
only  when  adding  or  deleting  a pre-stored  ETIS  advisory,  not  with 
each  message.)  A similar  preformatted  capability  would  allow 
retrieval  of  a frequently  used  ETIS  advisory  with  one  or  more 
parameters  to  be  inserted  by  the  controller.  An  example  is 
"Braking  action  poor  by  a 727 , “ where  the  underlined  data  is 
entered  by  the  controller. 

3.2.11  Time  of  Day 

It  may  be  desirable  to  include  with  each  initial  arrival  and 
departure  ETIS  message  the  time  of  day  at  which  the  data  were  ob- 
tained by  the  weather  sensor  system.  If  required  by  operational 
procedures  implemented  with  data  link,  this  time  tag  can  then  be 
passed  on  to  the  controller  by  the  pilot  at  initial  contact,  just 
as  is  done  with  the  ATIS  alpha  identifier  today.  However,  the  real 
time  nature  of  ETIS,  with  updates  (change  messages,  alerts,  etc.) 
being  provided  automatically  to  the  aircraft  after  receipt  of  in- 
itial ETIS,  obivates  the  need  for  this  exchange  between  pilot  and 
controller.  Rather,  an  acknowledgement  to  the  controller  "I  have 
data  link  ETIS"  should  be  sufficient  and  a time  ';ag  on  each 
message  is  not  required. 

Other  ETIS  messages  could  include  GMT  time  to  indicate  when 
an  event  was  detected,  or  when  the  message  went  into  effect.  An 
example  is  any  of  the  alert  messages.  Again,  however,  the  real 
time  nature  of  ETIS  is  such  when  a message  is  received  by  the  air- 
craft, it  is  understood  in  all  cases  that  it  is  current  as  of  the 
last  fraction  of  a minute.  In  any  event,  if  it  is  determined  that 
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3.3  SYSTEM  CONFIGURATION  AND  FUNCTIONAL  DESCRIPTION 


The  ETIS  system  on  the  ground  is  made  up  of  the  LPDS  at  each 
terminal  location  providing  ETIS  services,  and  system  operating 
software  in  the  AP  located  at  the  controlling  ATC  facility.  A 
single,  full  duplex  land  line  with  appropriate  modems  on  either 
end  connects  the  AP  with  the  LPDS.  Interfaces  with  other  ATC 
automation  functions  are  provided  through  the  AP.  (See  Figure 
3-1).  The  paragraphs  below  describe  the  functions  of  these 
primary  system  elements. 

3.3.1  Local  Processor  Display  System  (LPDS) 

Each  airport  for  which  ETIS  is  to  be  provided  must  have  an 
LPDS  installed  to  gather,  format,  and  output  ETIS  data.  The  level 
of  complexity  and  capabilities  of  the  available  automated  weather 
observation  systems,  and  other  local  factors  may  vary  among  dif- 
ferent installations  depending  upon  airport  size,  traffic,  system 
cost,  and  other  factors.  But  in  all  cases,  the  LPDS  consists  of  a 
processor  (probably  some  type  of  microprocessor)  with  appropriate 
interfaces  to  the  local  automated  weather  observation  system(s) , 
and  one  or  more  display/input  terminals.  In  addition,  a digitized 
voice  system  (DVS)  may  be  included  at  many  locations,  particularly 
those  with  ATIS  services  today.  The  DVS  allows  non-DABS  aircraft 
to  receive  an  initial  ETIS  broadcast  over  a VHF  channel  just  as 
they  receive  ATIS  today,  but  without  human  intervention  in  record- 
ing the  data.  The  DVS  is  driven  by  the  LPDS  processor  and  outputs 
the  same  basic  real  time  data  as  the  data  link.  The  DVS  also 
provides  ETIS  for  departures  at  those  sites  remote  from  the  DABS 
sensor  which  do  not  have  DABS  coverage  down  to  the  surface.  (See 
Section  3 . 3 . 2 . 2 . 2 . ) 

The  following  paragraphs  contain  detailed  discussions  of  the 
functions  of  the  LPDS  processor,  display/input  terminal,  and  DV^S. 

3. 3. 1.1  LPDS  Processor  - The  LPDS  processor  performs  the  local 
data  processing  and  control  functions  necessary  to  collect,  format 
and  output  the  locally  derived  ETIS  information.  It  is  envisioned 


that  this  LPDS  processor  is  dedicated  to  ETIS,  and  therefore  is  a 
major  part  of  the  new  equipment  required  for  implementing  ETIS.  Its 
importance  also  lies  in  the  fact  that  it  connects  all  weather  data 
and  ETIS  keyboard  inputs  to  the  AP  with  a single  communication 
link.  The  alternative  is  tieing  AV-AWOS,  LLWSAS,  and  terminal 
inputs  directly  to  the  AP,  which  will  service  more  than  one  ETIS 
and  may  be  remotely  located.  This  results  in  proliferation  of  the 
number  of  communication  lines  and  their  associated  lease  costs, 
lower  reliability,  etc.  Furthermore,  the  LPDS  processor  enables 
the  local  controller  or  airport  operator  to  have  direct  access  to 
ETIS  information  independent  of  the  integrity  of  the  link  to  the 
AP,  or  the  AP  itself.  The  LPDS  is  therefore  a stand-alone  system 
capable  of  providing  the  ETIS  data  directly  to  the  controller  and 
over  the  VHF  voice  channel  using  the  DVS  without  any  connection  to 
. the  AP.  This  provides  an  important  fail  soft  capability,  as  well 
as  an  independent  means  of  providing  ETIS  information  to  non-DABS- 
equipped  aircraft. 

One  alternative  that  should  be  mentioned  is  the  possibility  of 
combining  the  functions  of  the  automated  weather  sensor  system 
processor  (AV-AWOS)  with  those  of  the  LPDS  processor  into  a single 
integrated  system.  There  are  some  potential  advantages  to  this 
approach,  including  a reduction  in  the  amount  of  hardware,  elimina- 
tion of  a computer-to-computer  communication  link,  and  avoidance 
of  unnecessary  and  duplicative  data  processing,  all  of  which  impact 
cost  and  reliability.  And  the  ETIS  concept  assumes  the  existence 
of  an  AV-AWOS  type  system  to  provide  weather  observations,  so 
wherever  ETIS  is  implemented,  AV-AWOS  must  be  also.  Conceptually, 
combining  the  two  could  result  in  a very  neat  package. 

However,  it  is  not  clear  at  this  stage  whether  or  not  the 
objectives,  requirements,  design  constraints,  etc.  of  ETIS  and 
AV-AWOS  are  consistent,  and  their  combination  of  mutual  benefit. 
Also,  an  argument  can  always  be  made  for  decentralized  or  dis- 
tributed processing  in  cases  such  as  this.  At  least  for  the  sake 
of  clarity  in  presenting  the  concept,  a separate,  stand-alone 
LPDS  processor  is  assumed.  However,  the  data  link  and  weather 
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system  designers  should  give  careful  consideration  to  combining 
these  two  functions. 


The  major  functions  of  the  LPDS  processor  are  described 


below . 


3. 3. 1.1.1  Interface  with  Automated  Weather  Sensor  Systems  - In  the 
time  frame  of  interest  for  the  ETIS  concept  (mid  to  late  80's)  some 
type  of  automated  weather  observation  system  or  systems  (AV-AWOS, 
ALWOS,  WAVE,  LLWSAS)  will  probably  be  available,  and,  in  fact, 
implemented  at  a number  of  locations.  These  unmanned  observation 
systems  will  provide  real-time  continuous  surface  observations  for 
local  consumption  and  for  distribution  over  the  normal  weather  com- 
munication networks.  To  obtain  most,  if  not  all,  of  the  weather 
data  parameters  required  for  ETIS  (See  Table  3-2,  Section  3. 3. 2. 2) 
the  LPDS  will  simply  interface  with  one  or  more  of  these  colocated 
automated  observation  systems.  The  detailed  design  of  these  inter- 
faces is  not  important  for  the  purposes  of  developing  the  ETIS 
concept.  The  sensor  systems  may  be  polled  by  the  LPDS  processor, 
or  the  outputs  provided  continuously  or  on  an  interrupt  basis  by 
the  sensor  systems.  What  is  important  is  that  the  LPDS  design  and 
that  of  AV-AWOS,  ALWOS,  LLWSAS,  etc.,  be  compatible,  and  the  appro- 
priate interfaces  developed  early  in  the  design  process.  (As  stated 
earlier  in  Section  3.2,  the  automated  weather  sensor  systems  them- 
selves are  not  the  responsibility  of  the  ETIS  or  DABS  data  link 
designers,  although  their  presence  and  capabilities  are  included  as 
part  of  this  ETIS  concept.) 

3. 3. 1.1. 2 Process  Weather  Data  - The  LPDS  processor  will  process 
the  weather  data  to  the  extent  necessary  to  put  it  in  a form 
suitable  for  use  by  the  ETIS  software  in  the  AP.  The  processed 
data  will  also  be  outputted  to  the  local  display  to  provide  a 
complete  real-time  ETIS  report  to  the  controller,  and  to  the  DVS 
for  broadcast  to  non-DA6S-equipped  aircraft. 


The  processing  required  will  depend  upon  the  form  of  the  input 
data  and  the  requirements  of  the  AP,  display,  and  DVS.  It  is  ex- 
pected that  all  of  the  required  averaging,  smoothing,  and  other 
massaging  of  data  including  conversion  to  digital  form,  will  be 
done  by  the  AV-AWOS  (or  ALWOS  or  WAVE)  prior  to  transmission  to  the 
LPDS  processor.  Any  pressure  drop,  temperature  drop  and/or  thunder- 
storm alerts  are  also  expected  to  be  detected  by  the  automated 
weather  sensor  system  and  transmitted  to  the  LPDS  processor. 
Similarly,  the  wind  shear  alert  is  detected  by  the  LLWSAS  system, 
and  is  an  input  to  the  LPDS  processor. 

3. 3. 1.1. 3 Interface  with  Applications  Processor  - The  LPDS  pro- 
cessor outputs  locally  derived  data  to  the  AP  via  modems  and  a 
single  land  line.  This  line  may  be  time  shared  with  other  LPDS 
processors,  and  should  require  no  more  than  1200  bits  per  second. 

The  interface  will  probably  employ  a polling  scheme  with  the  AP 
polling  each  LPDS  processor  on  a periodic  or  as  required  basis. 

Only  data  which  have  changed  need  be  transmitted  during  a poll, 
but  this  will  depend  upon  the  detailed  design  of  the  interface. 
Certainly,  there  is  no  need  to  repeat  NOTAMS,  active  runway,  etc., 
with  each  poll.  Depending  upon  the  polling  rate,  a means  may  be 
required  whereby  the  LPDS  processor  signals  the  AP  that  an  alert 
(wind  shear,  etc.)  has  been  received,  so  that  the  AP  may  give 
immediate  attenuation  to  dispatching  it. 

3. 3. 1.1. 4 Interface  with  the  Display/ Input  Terminal  - The  LPDS 
processor  serves  two  primary  functions  via  the  interface  with  the 
display/ input  terminal.  It  receives  input  data  from  the  terminal 
in  the  form  of  operator  entered  data  (NOTAMS,  active  runway, 
advisories,  etc.),  and  outputs  the  locally  derived  data  in  a 
format  suitable  for  display  to  the  controller  or  airport  operator. 
Included  is  the  storage  of  preformatted  messages  and  other 
software  functions  to  assist  the  operator  in  entering  information. 
The  display  refresh  rate  is  controlled  by  the  LPDS  processor,  and 
will  be  on  the  order  of  once  every  10-15  seconds.  Again,  depending 
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upon  the  design  of  this  interface,  it  may  only  be  necessary  to  send 
data  that  have  changed,  rather  than  to  repeat  the  entire  set  of 
data , 

This  interface  will  actually  be  with  TIPS  in  those  locations 
where  it  is  installed.  It  may  also  drive  more  than  one  terminal 
in  some  cases  (sec  Section  3. 3. 1.2). 

3. 3. 1.1. 5 Drive  a Local  Digitized  Voice  System  - The  LPDS  proces- 
sor will  include  an  interface  to  drive  a local  DV'S,  which  in  turn 
transmits  over  a local  VOR  or  other  VHP  channel.  This  capability 
may  not  be  utilized  at  all  locations,  but  should  be  provided  as 

an  available  output  from  the  LPDS  processor.  The  specific  inter- 
face will  depend  on  the  DVS  design  and  how  best  to  share  the  neces- 
sary functions.  It  is  conceivable  that  the  vocabulary  could  be 
stored  in  the  LPDS  processor  memory,  and  the  ETIS  message  outputted 
to  the  DVS  in  the  form  of  reconstructed  digital  speech.  Alterna- 
tively, word  storage  could  be  a function  of  the  DVS,  and  some  type 
of  coded  output  from  the  LPDS  processor  would  drive  the  D\'S.  Bit 
rate  for  the  first  case  may  be  as  high  as  24,000  bps,  depending 
upon  the  technology  used,  but  would  certainly  be  greater  than  2400 
bps.  If  word  storage  is  within  the  DVS,  a bit  rate  of  only  about 
128  bps  is  required. 

The  data  outputted  by  the  LPDS  processor  to  drive  the  DVS 
comprises  a complete  ETIS  message,  much  the  same  as  the  ATIS  broad- 
cast of  today.  Although  the  data  are  updated  in  real  time,  it  is 
only  provided  on  a broadcast  basis,  so  that  alerts,  RVR,  sector 
winds,  etc.,  cannot  be  directed  to  specific  aircraft  during 
specific  phases  of  flight.  As  with  ATIS  today,  once  the  non-DABS- 
equipped  aircraft  has  received  the  ETIS  broadcast,  any  alerts  or 
other  significant  changes  to  the  data  must  be  given  to  the  pilot 
by  the  controller. 

3. 3. 1.1. 6 Self-Test  - The  LPDS  processor  will  perform  some  self- 
testing and  integrity  monitoring  of  the  various  interfaces, 
particularly  the  automated  weather  sensor  system  inputs.  Because 
the  LPDS  is  envisioned  as  a stand-alone  system  in  that  it  is 
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capable  of  providing  complete  F.TIS  data  to  the  local  controller 
or  airport  operator  without  connection  to  the  AP,  it  is  important 
that  the  validity  of  the  data  be  assured  prior  to  its  acceptance, 
and  that  system  errors  be  detected.  The  sensor  system  itself  will 
have  some  sel f -monitor ing  capability.  In  addition,  the  LPDS 
processor  will  have  sufficient  capability,  consistent  with  that 
of  the  sensor  system,  to  insure  that  data  are  received  correctly, 
that  they  pass  some  form  of  reasonableness  tests,  and  that  sensor 
outages  have  been  detected  and  are  flagged. 

3. 3. 1.2  Display/Input  Terminal  - The  di splay/ input  terminal  serves 
two  primary  functions  with  regard  to  ETIS.  It  displays  in  real 
time  the  complete  set  of  ETIS  data  derived  from  local  automated 
sensor  systems  and  manual  inputs,  and  it  provides  a means  whereby 
the  controller  or  airport  operator  can  enter  manual  data  for  in- 
clusion in  ETIS  messages.  In  actual  fact,  this  display / input 
terminal  is  likely  to  be  a TIPS  display  subsystem  in  those  loca- 
tions where  TIPS  is  available.  Otherwise,  a dedicated  display/ 
input  terminal  for  the  ETIS  function  will  be  required.  A con- 
ventional CRT  with  full  ASCII  keyboard  is  a likely  candidate. 

Whether  or  not  TIPS  is  available,  the  LPDS  may  include  other 
display/ input  terminals  located  elsewhere  at  the  airport.  Display 
of  ETIS  in  the  pilot's  lounge  or  airport  manager's  office,  for 
example,  makes  sense  at  the  large  airports.  But  more  than  one 
input  keyboard  is  unlikely  since  it  provides  direct  access  to  the 
LPDS  processor  for  making  changes  in  ETIS  data. 

The  terminal  displays  the  complete  ETIS  information  in  real 
time,  being  updated  several  times  a minute  by  the  LPDS  processor. 
Alert  messages  are  clearly  indicated  through  flashing,  dedicated 
display  area,  audible  warning,  or  a combination  of  these.  The 
display  format  is  designed  .so  that  the  data  can  be  easily  read  and 
interpreted  by  the  controller.  The  display  must  be  suitable  for 
installation  in  a tower  cab  environment,  and  readable  under 
conditions  of  bright  sunlight.  (See  Section  3.6.)  If 
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time  tags  are  required,  they  can  be  added  by  the  LPDS  or  the  AP, 
but  would  likely  be  included  in  the  data  from  the  automated  weather 
sensor  system,  as  it  is  with  AV-AWOS. 

The  terminal  also  provides  a means  for  manually  entering  data 
such  as  airport  advisories,  runway  in  use,  etc.  Both  the  display 
and  keyboard  are  used  for  this  function.  The  operator  (controller, 
etc.)  may  call-up  for  display  preformatted  messages  for  which  he 
may  fill  in  certain  data,  review  the  entire  message,  then  enter 
it  into  the  current  ETIS  information.  He  may  also  manually  com- 
pose a complete  airport  advisory  or  other  message  by  typing  it 
in  via  the  keyboard.  Again,  the  display  is  used  to  review  and 
correct  the  message  prior  to  entry  into  the  current  ETIS. 

The  LPDS  terminal  will  be  used  to  exercise  diagnostic  routines 
to  check  system  performance  and  to  input  manually  observed  data  in 
cases  of  automated  sensor  failure.  It  will  also  be  used  to  modify 
preformatted  messages  and  to  generate  and  store  nev;  ones. 


It  is  important  to  note  that  with  a DVS  connected  to  the  LPDS 
processor,  its  fixed  vocabulary  will  limit  the  words,  phrases,  and 
terminology  used  in  the  manually  inputted  advisories,  etc.  Care  in 
the  design  of  the  vocabulary  should  prevent  any  problems  in  this 
regard . 

3. 3. 1.3  Digitized  Voice  System  (DVS)  - Some  type  of  DVS  capability 
for  airports  which  have  ETIS  serves  a very  important  purpose.  It 
promises  complete  elimination  of  the  manually  operated  ATIS  system 
of  today,  while  still  providing  equivalent  or  better  service  to 
non-DABS-equipped  aircraft.  Assuming  that  it  will  be  a long  time 
before  all  aircraft  are  DABS  equipped,  DVS  should  receive  careful 
consideration.  DVS  also  provides  ETIS  for  departures  at  those 
remote  ETIS  equipped  airports  where  DABS  coverage  does  not  extend 
down  to  the  surface. 

The  basic  function  of  the  DVS  is  to  broadcast  the  ETIS  informa- 
tion over  a local  VOR  or  other  VHP  channel  utilizing  digitized  (or 
synthetic)  speech.  The  data  is  received  from  the  LPDS  processor 
either  in  some  coded  form  or  as  actual  digital  speech  (see  Section 
3. 3. 1.1. 5).  The  DVS  processes  the  coded  data  as  required, 
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retrieving  pre-stored  digitized  words  from  memory,  or  selecting 
the  proper  phonemes  in  the  case  of  synthetic  speech.  The  digital 
speech  is  converted  to  analog  form  and  transmitted  over  the 


I VHP  channel. 

The  DVS  operates  in  a broadcast  mode  only,  having  no  discrete 
address  capability  over  the  VHP  channel.  It  functions  in  a manner 
similar  to  the  recorded  ATIS  broadcast  of  today.  A pilot  tunes  to 
the  DVS  frequency,  listens  to  the  broadcast,  and  records  the 
pertinent  information.  He  does  not  remain  on  the  DVS  frequency, 
so  any  alerts  or  significant  changes  in  data  must  be  given  to  him 
by  the  controller,  as  well  as  RVR  and  wind  on  final  approach,  as 
is  current  practice.  Thus,  the  DVS  completely  eliminates  the  need 
for  the  conventional  ATIS  broadcast,  and  derives  its  real  time  data 
automatically  from  the  ETIS  system.  The  result  is  an  overall 
reduction  in  controller  workload. 

3.3.2  ETIS  Operating  Software 

The  ETIS  operating  software  is  located  in  the  AP  at  the  con- 
trolling ATC  facility,  and  services  one  or  more  ETIS  installations 
within  coverage  of  the  associated  DABS  sensor.  As  pointed  out 
earlier,  this  concept  assumes  a separate  AP  dedicated  to  data  link 
applications  requirements.  In  future  operational  DABS  systems, 
these  processing  functions  may,  in  fact,  be  combined  with  other 
DABS  functions  and  be  performed  in  a DABS  processor.  This  imple- 
mentation detail  is  not  important  for  the  purposes  of  presenting 
the  ETIS  concept. 

The  functions  of  tl.e  ETIS  operating  software  are  the  following: 


a . 

Collect  and  process  ETIS 

data  from  the  LPDS's 

b. 

Generate  and  format  ETIS 

messages 

c . 

Dispatch  ETIS  messages 

d. 

Interface  with  TIPS 

e . 

Exchange  data  with  other 

AP’s. 

The  paragraphs  below  describe  each  of  the  above  functions  in  detail. 


1 
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3.3.2.  1 Clollect  and  Process  ETIS  Data  - The  ETIS  operating  software 
within  the  AP  collects  and  processes  all  the  locally  generated  real- 
time liTIS  data  from  each  LPDS  within  coverage  of  the  associated 
DABS  sensor.  These  data  are  processed  by  the  ETIS  software  to  the 
extent  necessary  to  put  them  in  a form  suitable  for  use  in  ETIS 
messages.  The  data  are  then  stored  within  the  AP  and  are  con- 
tinuously available  for  insertion  into  an  ETIS  message. 

The  extent  of  processing  of  the  ETIS  data  within  the  AP 
depends  upon  the  characteristics  of  the  data  as  received  from  the 
LPDS,  and  may  in  fact  prove  to  be  minimal  since  the  concept  calls 
for  stand-alone  capability  for  the  LPDS  in  providing  essentially 
complete  ETIS  information  for  local  consumption.  However,  some 
data  processing  is  likely  to  remain  a function  of  the  ETIS  software, 
such  as  wind  shear  vector  difference  calculations,  density  altitude, 
and  detection  of  conditions  below  VFR  minimums.  Nevertheless,  all 
of  these  functions  can  be  performed  by  the  LPDS  processor. 

The  stored  ETIS  data  is  updated  several  times  per  minute  by 
polling  each  LPDS  under  control  of  the  ETIS  software.  A single, 
full  duplex,  time-shared  interface  at  around  4800  bps  is  a suitable 
interface  for  this  function,  based  on  the  number  of  parameters  to 
be  transmitted,  update  rates  of  3-4  times  per  minute,  and  8-10  air- 
ports with  ETIS  per  AP.  However,  considering  that  current  plans 
call  for  initially  deploying  TIPS  at  locations  that  are  prime 
candidates  for  ETIS  (high  and  medium  activity  terminal  environ- 
ments), an  alternative  interface  between  the  AP  and  LPDS  is 
through  TIPS  (see  Figure  3-1).  This  offers  the  advantage  of  fewer 
land  lines  and  recognizes  that  the  LPDS  will  probably  interface 
directly  with  the  local  TIPS  tower  display  subsystem  anyway.  (See 
Section  3. 3. 1.2.)  This  alternative  may  reduce  the  flexibility  of 
the  ETIS  design,  however,  and  the  current  TIPS  design  makes  pro- 
visions for  manual  input  of  locally  observed  weather  only.  This  is 
not  viewed  as  a serious  obstacle,  however. 


3. 3. 2. 2 Generate  and  Format  ETIS  Messages  - The  ETIS  operating 
software  generates  and  formats  all  ETIS  messages  utilizing  the 
stored  ETIS  data.  More  specifically,  the  ETIS  software  establishes 
the  required  contents  of  the  message,  extracts  the  necessary  data 
from  the  memory  area  for  the  airport  of  interest,  inserts  and 
properly  formats  the  data  in  the  message,  and  hands  over  the  mes- 
sage to  the  AP  communications  control  software.  The  specific  format 
of  the  message  at  this  point  depends  upon  the  design  of  the  inter- 
face between  the  ETIS  operating  software  and  the  communications 
control  software  within  the  AP.  The  format  at  this  interface  could 
be  anywhere  from  a highly  coded,  final  form  ready  for  uplink  to  the 
aircraft,  to  simply  a string  of  ASCII  characters  representing  the 
data  elements  to  be  transmitted.  The  details  of  this  interface  will 
be  handled  in  the  design  of  the  AP  software,  and  the  data  link  mes- 
sage formats  and  protocol. 

Table  3-2  shows  the  various  messages  which  are  generated  by 
ETIS,  their  content,  and  when  they  are  dispatched.  They  are  dis- 
cussed in  Section  3. 3. 2. 3. 

3. 3. 2. 2.1  Initial  Arrival  ETIS  - The  Initial  Arrival  ETIS  is  sent 
to  all  aircraft  whose  destination  is  the  airport  of  interest  at  a 
predetermined  point  upon  arrival  in  the  terminal  area.  (See  Section 
3. 3. 2. 3.1.)  It  is  also  sent  to  any  aircraft  requesting  ETIS  for  a 
specific  location.  The  contents  of  the  message  include  essentially 
all  ETIS  data,  as  indicated  in  Table  3-2,  with  the  exception  of 
runway  wind.  Any  alerts  are  included  if  applicable,  and  RVR  and 
density  altitude  only  if  the  criteria  for  their  inclusion  are  met. 
(See  Sections  3.2.4  and  3.2.9).  Time  of  day  may  be  included  at 

the  beginning  of  this  message  primarily  for  unique  identification 
of  the  data  (replacing  the  alpha  designator  of  ATIS) . 

3. 3. 2. 2. 2 Departure  ETIS  - Depature  ETIS  is  sent  upon  request 
to  an  aircraft  prior  to  its  departure.  (See  Section  3. 3. 2. 3. 2). 

Its  contents  are  essentially  the  same  as  the  initial  arrival 

ETIS  with  the  exception  that  approach  in  use  and  RVR  are  not 
included.  Time  of  day  maybe  included  for  the  same  reason  as  for 
initial  arrival  ETIS, 
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TABLE  3-2.  ETIS  MESSAGE  TYPES 


1 


MESSAGE  TYPE 

CONTENT 

WHEN  DISPATCHED 

1.  Initial  Arrival  ETIS 

I, 2, 3, 4, 5, 6*. 7, 10, 

II,  12, 16*, 17, 18, 
(8,9,13,14,15)** 

Prior  to  arrival  at  entry  fix. 

2.  Departure  ETIS 

1,3, 4, 5, 6*, 7, 10, 11, 
12, 16*, 17, 18,  (8,9, 
13,14,15)** 

Upon  pilot  request 

3.  Final  Approach 

4*  or  6*, 7, 8, 

Near  outer  marker  or  final 
approach  fix 

4.  Chanije-Runways  in  Use 

1 

When  changed 

5 . Change-Approach  in 

Use 

2 

When  changed 

6.  Change-Altimeter 
Setting 

12 

When  value  changes  by  pre- 
determined amount 

7.  Change-Visibility 
and/or  Precip.  Type 

^.5 

When  value  changes  by  pre- 
determined amount 

8.  Change-Ceiling 

When  value  changes  by  pre- 
determined amount 

9 . Change-RVR 

6 

. . 

When  value  changes  by  pre- 
determined amount 

10.  VFR  Minimums 

13,4 

When  conditions  go  below  VFR 
minimums 

11.  Airport  Advisories 

.1.7  _ 

When  put  into  effect 

12.  Wind  Shear  Alert 

7 8.9 

When  detected 

13.  Pressure  Juinp  Alert 

12.13 

When  detected 

14.  Temp.  Drop  Alert 

10,14 

When  detected 

1^.  Thunderstorm  Alert 

15 

When  detected 

16.  Pilot  Request 

Response 

As  requested 

lipon  receipt 

MESSAGE  CONTENTS 

1.  Ronway(s)  in  Use  (Approach  and  Departure) 

2.  Approach(es)  in  Use 

3.  Sky  Condition 

4.  Prevailing  Visibility 

5.  Precipitation  Type 

6.  RVR 

7.  Center  Field  Wind 

8.  Runway  or  Sector  Wind  (Only  for  Runway(s)  in  Use) 

9.  Center  Field/Runway  Wind  Vector  Difference  (speed,  direction) 

10.  Temperature 

11.  Dewpoint 

12.  Altimeter  Setting 

13.  Rate  of  Barometric  Pressure  Rise  ( inches  Hg  in  minutes) 

14.  Rate  of  Temperature  Drop  ( degrees  F in  minutes) 

13.  Thunderstorm  location,  direction,  speed  (if  available) 

16.  Density  Altitude 

17.  Airport  Advisories 

18.  Time  of  Day  of  ETIS  Data  (if  required) 

*If  conditions  warrant. 

**0nly  when  the  associated  alert  is  in  effect. 

t 


The  technical  feasibility  of  providing  departure  ETIS  via 
data  link  is  not  yet  clearly  established,  due  to  the  uncertainties 
regarding  DABS  coverage  down  to  the  surface.  This  is  particularly 
true  for  those  ETIS  equipped  airports  remote  from  the  DABS  sensor. 
In  these  cases,  it  is  unlikely  that  departure  ETIS  can  be  provided 
by  data  link,  and  use  of  the  DVS  over  the  VHP  channel  will  be 
necessary  (as  it  is  today).  Arrival  ETIS  and  all  other  messages 
prior  to  final  approach  will  be  sent  via  data  link  at  these 
locations.  Once  the  aircraft  begins  to  descend  on  final,  however, 
there  will  be  a point  prior  to  touchdown  where  DABS  coverage  will 
be  lost.  Standard  operating  procedures  must  be  implemented  to 
account  for  these  situations  to  insure  that  all  pertinent  data 
reaches  the  pilot,  either  via  data  link  or  voice. 

The  situation  regarding  departure  ETIS  at  those  airports  co- 
located with  the  DABS  sensor  is  less  clear.  While  there  may  be 
DABS  coverage  on  parts  of  the  airport  surface,  there  will  almost 
surely  be  areas  where  blockage  from  structures,  etc.,  will  prevent 
reliable  data  link  operation.  If  this  in  fact  is  the  case,  and 
ETIS  cannot  be  satisfactorily  provided  at  these  locations,  the  VRS 
broadcast  over  the  VHP  channel  will  again  be  used. 

This  question  of  DABS  coverage  on  the  surface  adds  another 
argument  in  favor  of  implementing  the  DVS  broadcast  along  with 
ETIS. 


3. 3. 2. 2. 3 Pinal  Approach  Data  - This  ETIS  message  contains  center 
field  wind,  runway  wind,  and  RVR  or  prevailing  visibility,  which- 
ever is  appropriate  for  the  approach  in  use,  but  only  if  the  RVP 
is  less  than  6000  feet  of  if  visibility  is  less  than  2 miles.  (See 
Sections  3.2.3  and  3.2.4.)  The  message  is  automatically  sent 
after  the  aircraft  has  been  cleared  for  the  approach. 

The  ETIS  software  monitors  RVR  and  prevailing  visibility, 
and  based  on  the  approach  in  use,  determines  whether  or  not  to 
include  either  of  these  parameters  in  the  final  approach  data 
message.  Runway  in  use  is  used  by  the  software  to  determine  which 
RVR  and  runway  wind  data  to  include  in  the  message. 


3-25 


In  those  instances  where  more  than  one  runway  is  in  use  for 
landing,  a number  of  alternatives  exist.  The  simplest  is  to  in- 
clude merely  the  wind  and  RVR  data  for  all  runways  in  use  and  de- 
pend on  the  pilot  to  ignore  all  but  the  one  of  interest  to  him. 
Second,  the  assigned  runway  can  be  obtained  from  TIPS  if  an  algorithm 
is  developed  for  this  purpose  or  if  entered  by  the  controller.  Pro- 
visions are  made  in  the  message  structure  of  TIPS  for  this 
capability.  Third,  surveillance  data  and  altitude  filtering  can 
be  used  by  the  ETIS  software  to  determine  which  runway  an  aircraft 
has  been  assigned.  Finally,  the  pilot  can  be  asked  to  enter  via 
keyboard  the  assigned  runway  which  would  either  be  downlinked  for 
use  by  ETIS  software,  or  merely  serve  to  filter  the  data  as  re- 
ceived onboard  the  aircraft. 

The  first  alternative  is  unattractive  to  the  pilot,  but  may 
be  acceptable.  The  last  alternative  is  not  only  unattractive  to 
the  pilot,  but  increases  his  workload  as  well,  and  is  likely  to 
be  unacceptable.  Option  three  is  more  complex  to  implement  in 
the  ground  system,  but  is  certainly  feasible.  DABS  will  provide 
sufficient  accuracy  and  resolution  to  distinguish  between  parallel 
runways  when  both  are  in  use.  This  alternative  becomes  more 
attractive  if  surveillance  data  are  used  by  ETIS  for  other  pur- 
poses and  by  other  data  link  services.  (See  Section  3. 3. 2. 3.) 

The  second  alternative  seems  most  attractive  for  several 
reasons.  Airports  with  multiple  instrumented  runways  which  are 
used  simultaneously  are  generally  the  larger  ones,  and  therefore 
most  likely  to  have  TIPS.  If  the  assigned  runway  is  either  deter- 
mined by  an  algorithm  or  entered  by  the  controller,  ETIS  software 
can  easily  use  it  and  no  additional  workload  is  required  of  pilot 
or  controller.  And  if  the  controller  is  required  to  enter  the 

assigned  runway  via  TIPS  solely  for  ETIS,  it  does  not  represent  a 
net  increase  in  workload  since  he  will  not  then  be  required  to 
provide  RVR  or  wind  to  that  aircraft  on  final  approach. 


It  is  proposed  that  the  ETIS  software  obtain  runway  assignment 
from  TIPS  when  more  than  one  is  in  use.  When  TIPS  is  not 
available  or  no  runway  assignment  is  present  in  TIPS,  surveil- 
lance data  will  be  used  to  distinguish  between  runways. 

3. 3. 2. 2. 4 Parameter  Change  Messages  - Parameter  change  messages 
are  automatically  transmitted  to  an  aircraft  when  a parameter 
changes  by  certain  predetermined  criteria.  Change  messages  are 
advisory  in  nature,  as  distinguished  from  alerts,  which  warn  of 
potentially  hazardous  conditions.  The  contents  of  the  message 
are  the  new  value  of  the  parameter.  As  indicated  in  Table  3-2, 
changes  in  runway  or  approach  in  use,  altimeter  setting,  visibility 
and/or  precipitation  type,  ceiling,  and  RVR  are  included  in  this 
category . 

The  criteria  for  dispatching  change  messages  are  discussed  in 
Section  3. 3. 2. 3. 2.  The  ETIS  software  will  send  the  appropriate 
change  message  to  all  aircraft  which  have  received  an  initial 
arrival  or  departure  ETIS  message.^  However,  runway  and  approach 
in  use  change  messages  will  not  be  sent  to  an  aircraft  already 
established  on  approach,  that  is,  an  aircraft  which  has  received 
the  final  approach  data  message. 

3. 3. 2. 2. 5 VFR  Minimums  Message  - When  the  ceiling  and/or  visibility 
drop  below  VFR  minimums  (1000  feet  and  3 miles  respectively),  a 
message  indicating  conditions  below  VFR  minimums  is  sent  to  all 
aircraft  which  have  received  the  initial  arrival  or  departure 

ETIS.  The  message  contains  the  current  ceiling  and  visibility 
values.  This  message  is  aimed  primarily  at  VFR  aircraft  desiring 
to  land  at  or  depart  from  the  airport  to  warn  them  that  VFR  flight 


‘'This  necessitates  creation  of  a table  of  aircraft  and  their 
status  within  the  ETIS  software. 
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cannot  be  conducted  in  the  area  and  to  file  IFR  if  they  are 
qualified.  The  message  is  also  useful  for  IFR  operations  to 
alert  them  of  the  deteriorating  conditions,  and  will  be  sent 
to  these  aircraft  as  well. 

It  is  expected  that  the  value  of  the  ceiling  (lowest  cloud 
layer  covering  601  or  more  of  the  sky)  will  be  a direct  input  from 
the  automated  weather  sensors.  However,  it  could  be  easily 
calculated  by  the  F.TIS  software  from  the  sky  condition  data  if 
necessary . 


5. 3. 2. 2. 6 Airport  Advisory  - These  messages  are  the  result  of 
additions  or  changes  to  the  Airport  advisories  pertaining  to  a 
given  airport.  All  aircraft  which  have  received  an  initial  ar- 
rival LTIS,  or  the  departure  ETIS,  will  be  sent  an  Airport 
advisory  message  when  it  has  been  inputted  by  the  controller.  The 
content  of  the  message  is  the  Airport  advisory  itself,  and  is 
automatically  added  to  all  initial  arrival  or  departure  ETIS  mes- 
sages as  well. 


3. 3. 2. 2. 7 Alert  Messages  - Alert  messages  are  intended  to  inform 
the  pilot  on  a real-time  basis  of  the  existence  of,  or  potential 
existence  of,  hazardous  conditions  in  the  terminal  area.  The 
alerts  as  envisioned  here  involve  wind  shear  and  thunderstorm 
activity,  but  others  may  be  developed  in  the  future,  such  as  wake 
vortex  detection.  All  alerts  are  sent  to  all  aircraft  which  have 
received  the  initial  arrival  or  departure  ETIS. 


Wind  shear  alerts  are  obtained  directly  from  the  LLWSAS,  which 
compares  center  field  wind  with  each  of  five  boundary  winds  and 
generates  an  alert  when  the  vector  difference  exceeds  15  knots 
(nominally).  The  contents  of  this  ETIS  alert  message  are  the 
center  field  and  appropriate  sector  winds  (magnitude  and  direction). 
The  difference  between  these  two  winds,  magnitude  only  or  both 
direction  and  magnitude,  can  also  be  provided  if  this  is  considered 
useful  to  the  pilot.  If  not  available  directly  from  LLWSAS,  it 
can  be  readily  calculated  by  the  ETIS  software.  Alternatively,  the 
runway  and  crosswind  components  of  the  various  winds,  with  respect 
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to  the  active  runway,  could  be  calculated  by  the  ETIS  software  and 
presented  to  the  pilot.  The  preferable  approach  is  not  clear  at 
this  time,  and  other  alternatives  are  certainly  possible.  More 
study,  experimentation,  and  pilot  feedback  are  required  to  select 
a suitable  approach.  However,  implementation  of  any  of  these  by 
the  ETIS  software  should  be  straightforward. 

Detection  of  pressure  jumps  and/or  raoid  temperature  drops  have 
potential  use  as  thunderstorm  alerts.  Prior  to  the  development  of 
more  accurate,  reliable  thunderstorm  detection  and  monitoring 
capability,  these  data  may  prove  beneficial  in  providing  an  early 
warning  to  the  pilot  of  conditions  in  which  thunderstorm  activity 
might  occur.  While  specific  numbers  are  difficult  to  specify  at 
this  time,  and  are  not  the  responsibility  of  the  DABS  data  link 
designers,  a temperature  drop  on  the  order  of  3-5°?  in  5 minutes, 
or  a pressure  jump  of  around  2 millibars  in  2 minutes,  are  re- 
presentative. The  results  of  current  activities  in  this  area  will 
help  firm  up  these  numbers.  These  alerts  would  be  detected  by 
AV-AWOS  (or  ALWOS , etc.)  and  the  data  may  include  the  rate  of  change 
of  the  parameter,  which  could  be  sent  along  with  the  new  value  in 
the  data  link  message. 

Depending  upon  the  sophistication  and  capability  of  thunder- 
storm detection  equipment,  the  location,  direction,  and  speed  may 
all  be  available  for  a thunderstorm  alert  message.  Frequent  up- 
dating would  keep  pilots  informed  of  the  storm's  progress.  The 
ETIS  software  will  not  perform  any  of  the  detection  algorithms, 
but  merely  forward  the  data  in  an  alert  message.  The  actual 
detection  and  tracking  algorithms  will  be  part  of  AV-AWOS  or 
other  automated  weather  observation  system,  including  the  rate 
of  update  based  on  speed  of  movement  and  proximity  to  the  airport. 

3. 3. 2. 2. 8 Pilot  Request  Responses  - ETIS  must  be  capable  of  re- 
sponding to  a pilot  request  for  any  part  or  all  of  the  ETIS  data 
for  a specified  location.  A VFR  pilot  passing  through  the  area 
may  only  want  altimeter  setting,  or  a pilot  planning  his  approach 
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may  just  want  to  check  the  winds.  The  following  are  suggested 
subsets  of  ETIS  data  that  can  be  requested  by  the  pilot: 


1.  Full  ETIS  (Initial  Arrival  ETIS) 

2.  Sky  Condition 

3.  Prevailing  Visibility/Precipitation 

4.  Winds  (center  field  plus  active  runway) 

5.  Altimeter  Setting 

6.  RVR  (active  runway) 

7.  Temperature/Dewpoint 

8.  Approaches/Runways  in  Use 

9.  Airport  Advisories 

10.  Discontinue. 

Added  to  all  of  these  requested  data  messages  will  be  any  alerts 
v/hich  are  currently  in  effect  for  the  terminal  involved. 

The  means  by  which  the  pilot  generates  a request  of  the  above 
type  is  dependent  upon  many  factors  in  addition  to  the  ETIS  con- 
cept itself,  and  can  not  be  established  at  this  point.  Avionics 
design  and  cost  tradeoffs,  message  coding,  other  types  of  request 
messages,  pilot  preference,  etc.  must  all  be  considered.  One 
reasonable  approach  is  to  present  the  pilot  with  a "menu"  of  the 
above  data  request  types  after  he  enters  a general  ETIS  request 
input  to  his  avionics.  He  then  selects  the  desired  data  subset  by 
simply  entering  the  corresponding  number  identification.  (An  entry 
of  the  location  identifier  would  also  be  required.)  This  is  all 
handled  within  the  avionics  itself,  the  downlink  request  message 
being  sent  only  after  the  specific  selection  is  complete.  The 
pilot  should  also  have  the  option  of  selecting  a "one  time"  only 
request  versus  automatically  receiving  any  updates  of  the  data 
initially  requested.  The  ability  to  request  discontinuation  of 
ETIS  service  should  also  be  provided.  All  of  these  requests  can 
be  handled  within  the  above  approach  by  selection  of  suitable  menu 
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ETIS  REPORT  REQUEST  LOG  ID 
REPORT  TYPE 
UPDATES?  Y/N 

REPORT  TYPES: 


1-FULL  ETIS  2-SKY  CONDITION 

3-VISIBILITY  4-WINDS 
5-ALTIMETER  6-RVR 

7-TEMP/DEW  PT  8-RWY/APR  IN  USE 
9-ADVISORIES  O-DISCONTINUE 


FIGURE  3-2.  CANDIDATE  ETIS  DOWNLINK  REQUEST  "MENU"  AND  FORMAT 


items.  Figure  3-2  shows  a possible  avionics  display  format  for 
generating  an  ETIS  request  message  based  on  a 10  line,  32  character 
per  line  display  format. 


Other  schemes  are  possible,  as  are  other  groupings  of  the  data 
elements.  The  latter  is  the  most  important  factor  to  the  F.TIS 
concept,  however,  and  the  F.TIS  software  must  be  designed  to  re- 
cognize and  respond  to  specific  ETIS  requests  in  whatever  form  is 
established.  It  must  also  be  capable  of  providing  ETIS  data  to 
other  AP's  in  response  to  pilot  requests  which  occur  outside  the 
coverage  area  of  the  corresponding  DABS  sensor.  (See  Section 
3. 3. 2. 4.) 

3. 3. 2. 3 Dispatch  ETIS  Messages  - All  F.TIS  messages  are  dispatched 
under  control  of  the  ETIS  operating  software.  This  function  in- 
cludes determining  when  the  criteria  have  been  met  for  dispatching 
a message,  what  type  of  message  is  involved,  and  what  aircraft  are 
to  receive  it.  It  also  includes  discontinuing  ETIS  service  at  the 
appropriate  time. 

There  are  three  types  of  criteria  or  events  which  indicate 
when  a message  should  be  dispatched;  phase  of  flight  or  aircraft 
location,  a change  or  occurrence  in  the  ETIS  data,  and  pilot 
request.  When  one  of  these  events  occurs,  a specific  F.TIS  message 
must  be  generated  by  the  software  and  dispatched  to  one  or  more 
aircraft,  depending  upon  the  type  of  message  involved  and  the  event 
which  triggered  it.  There  are  also  three  conditions  under  which 
ETIS  services  are  discontinued  for  a particular  aircraft;  after 
landing,  after  departing  the  airport,  or  upon  pilot  request.  The 
paragraphs  below  discuss  these  conditions  and  criteria  in  more 
detail,  and  relate  them  to  the  various  message  types.  (Refer  to 
Table  3-2.) 

3. 3. 2. 3.1  Phase  of  Flight  or  Aircraft  Location  - There  are  two 
points  in  the  flight  of  an  aircraft  arriving  in  an  FTIS-equipped 
terminal  area  at  which  an  ETIS  message  is  autom.at  ical ly  dispatched. 
The  first  of  these  occurs  a short  time  prior  to  the  aircraft  being 
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handed  over  from  enroute  to  approach  control  (near  the  feeder  or 
coordination  fix).  This  point  varies,  depending  upon  the  terminal 
involved  and  the  route  by  which  the  aircraft  is  approaching,  but 
is  generally  20-50  miles  out.  When  an  aircraft  whose  destination 
is  an  F.TlS-equipped  airport  arrives  in  the  vicinity  of  this  point, 
the  initial  arrival  ETIS  message  will  be  automatically  sent'. 

There  are  several  alternatives  for  dispatching  this  message, 
each  of  which  require  aircraft  destination  information.  Surveil- 
lance data  can  be  used  by  the  ETIS  software  to  detect  arrival  at  a 
specific  point,  or  perhaps  arriving  within  a fixed  radius  of  the 
airport  which  encompasses  all  feeder  fixes.  A second  alternative 
is  detection  of  the  handoff  event  between  enroute  and  approach 
control,  available  from  TIPS  or  ARTS.  However,  this  is  inconsis- 
tent with  today's  procedures,  which  require  the  pilot  to  obtain 
ATIS  prior  to  this.  A third  alternative  is  to  dispatch  the  mes- 
sage at  some  fixed  time  (5-10  minutes)  prior  to  the  aircraft's 
estimated  time  of  arrival  (ETA)  at  the  feeder  fix,  also  available 
from  TIPS  or  ARTS.  However,  the  accuracy  of  this  ETA  with  respect 
to  actual  aircraft  arrival  time  may  not  be  su^-ficient  for  this 
application.  The  recommended  approach  is  to  use  surveillance  data 
and  establish  a fixed  radius  at  each  airport  as  the  criterion  for 
dispatching  the  message. 

In  some  cases,  an  aircraft  may  be  landing  at  an  ETlS-equipped 
airport  but  no  destination  information  is  contained  in  TIPS  or 
ARTS.  An  example  is  a VFR  flight  with  no  flight  plan  on  file.  In 
this  case,  it  is  the  pilot's  responsibility  to  request  the  ETIS, 
which  is  always  available,  and  which  is  similar  to  today's  pro- 
cedure for  obtaining  ATIS.  The  ETIS  software  will  assume  from  thi 
request  that  the  aircraft  is  bound  for  the  airport  for  which  ETIS 
was  requested,  and  will  treat  it  as  a normal  arrival  from  this 
point  on.  An  alternative  way  to  handle  this  situation  is  to 
automatically  request  destination  information  via  the  data  link 
from  any  DABS- equipped  aircraft  which  is  within  coverage  but  does 
not  have  a destination  associated  with  it.  The  destination 
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information  would  have  to  be  entered  by  the  pilot.  However,  there 
is  no  apparent  advantage  to  this  approach;  it  is  more  complex  and 
less  flexible  for  the  pilot,  and  is  therefore  not  recommended. 

Another  factor  which  must  be  considered  in  dispatching  the 
initial  arrival  F.TIS  message  is  the  case  in  which  an  airport  with 
F.TIS  capability  is  located  near  the  outer  boundary  of  the  DABS 
sensor  coverage.  Aircraft  approaching  this  airport  may  not  be 
within  coverage  of  the  associated  DABS  sensor  until  well  beyond 
the  point  at  which  initial  arrival  ETIS  must  be  sent.  In  other 
words,  the  point  at  which  the  message  is  to  be  sent  is  within 
coverage  of  another  DABS  sensor.  The  AP  associated  with  this 
second  DABS  sensor  must  obtain  the  ETIS  data  from  the  first  AP  and 
dispatch  it  at  the  proper  time.  This  points  out  the  need  for 
netting  together  of  the  AP ' s as  discussed  in  Section  3. 3. 2. 5.  If 
there  is  no  adjacent  DABS  sensor,  the  pilot  is  forced  to  obtain 
the  initial  arrival  ETIS  from  the  DVS  over  the  conventional  VI!F 
channel . 

The  second  point  in  an  arrival  aircraft's  flight  when  ETIS 
messages  are  dispatched  is  somewhere  near  the  outer  marker  or  final 
approach  fix.  The  final  approach  data  message  is  automatically 
sent  to  the  aircraft  at  this  point  by  the  ETIS  software.  The  mes- 
sage can  be  dispatched  based  on  surveillance  data,  or  the  handoff 
from  approach  to  local  controller  can  be  used.  The  latter  event 
will  be  available  from  TIPS  and  occurs  at  the  same  time  in  the 
flight  that  this  data  is  given  today  by  the  local  controller. 
However,  if  surveillance  data  is  to  be  used  by  ETIS  for  other 
purposes,  it  can  be  used  equally  well  here. 

3. 3. 2. 3. 2 Change  in  ETIS  Data  - Certain  ETIS  message  types  are 
dispatched  when  a significant  change  occurs  in  the  ETIS  data. 
Included  in  these  message  types  are  alerts,  VFR  minimums,  and 
parameter  change  messages,  as  defined  in  Table  3-2.  The  ETIS 
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software  dispatches  these  messages  when  the  appropriate  pre- 
determined criteria  are  met,  or  when  certain  types  of  incoming 
data  messages  or  alerts  are  received  from  the  automated  weather 
sensor  systems.  Depending  on  the  message  type,  it  may  be  dis- 
patched to  all  aircraft  in  the  area  or  only  to  individual  air- 
craft. 

The  criteria  for  dispatching  these  messages  are  straight- 
forward in  some  cases,  but  not  so  easily  determined  in  others. 
Change  messages  are  intended  to  provide  an  update  to  the  pilot 
of  a parameter  he  has  already  obtained  from  the  initial  arrival 
or  departure  ETIS,  and  so  the  amount  of  change  significant  enough 
to  trigger  such  a message  must  be  carefully  established.  The 
DABS  data  link  designers  are  not  responsible  for  determining  these 
criteria,  but  rather  for  implementing  them  within  the  ETIS  soft- 
ware as  required.  Nevertheless,  some  discussion  of  what  these 
criteria  might  be  in  each  case  is  in  order. 

Under  current  weather  reporting  procedures  defined  in  the 
Federal  Meteorological  Handbook  (FMH-1)  certain  events  or  changes 
in  parameters  lead  to  the  issuance  of  a Special  Observat ion (SP) . 
When  an  SP  pertains  to  a given  airport,  all  arriving  aircraft 
under  approach  control  are  informed  of  the  SP  by  the  controller 
until  the  ATIS  is  appropriately  updated  and  is  being  received  by 
arriving  aircraft.  The  current  AV-AWOS  specification  calls  for 
automatic  detection  and  dissemination  of  SP's  based  on  essentially 
the  same  criteria  as  defined  in  FMH-1.  It  is  reasonable  to 
assume,  therefore,  that  the  primary  criterion  for  dispatch  of  a 
parameter  change  message  by  ETIS  should  be  the  receipt  of  an  SP 
from  AV-AWOS. 

In  addition  to  the  receipt  of  SP's,  it  may  be  desirable  for 
other  parameter  changer  or  events  to  cause  the  dispatch  of  an  ETIS 
change  message.  Because  data  link  with  ETIS  will  relieve  the 
controller  of  giving  such  messages  by  voice,  and  of  updating  the 
ATIS  tape,  it  may,  in  some  instances,  be  beneficial  to  give  the 
pilot  updates  triggered  by  smaller  changes  in  the  parameter  than 
is  done  manually  today.  The  real  time,  automated  aspect  of  ETIS 


has  the  potential  for  significantly  improving  the  amount,  quality, 
and  timeliness  of  such  data  while  actually  reducing  controller 
workload.  This  should  be  considered  by  the  designers  of  the 
weather  dissemination  criteria,  but  must  also  be  carefully  weighed 
against  the  danger  of  saturating  the  link  and  the  cockpit  with 
too  much  information. 

The  paragraphs  below  contain  discussions  of  the  criteria  to 
be  used  for  the  dispatch  of  each  of  the  message  types  which 
depend  on  a parameter  change  or  other  occurrence. 

Change  in  Runways  or  Approach  in  Use  - This  change  message  is 
straightforward.  It  is  dispatched  to  all  aircraft^  except  those 
which  are  already  established  on  final  approach,  when  the  change 
has  been  made  by  the  controller  via  the  LPDS  display/ input  terminal 
of  the  TIPS  tower  display  subsystem. 

Change  in  Altimeter  Setting  - Altimeter  setting  is  critical  to  all 
phases  of  flight.  The  most  reasonable  approach  is  to  dispatch 
this  message  to  all  aircraft  whenever  a change  of  .01  inches 
occurs.  Because  the  altimeter  setting  normally  changes  at  very 
slow  rates,  this  should  not  result  in  excessive  altimeter  setting 
updates  to  the  aircraft. 

Under  today's  procedures,  the  approach  controller  provides 
the  current  altimeter  setting  upon  initial  contact  with  the  pilot, 
and  may  or  may  not  update  this  if  small  changes  occur,  depending 
upon  the  current  conditions  and  his  own  judgment.  If  a pressure 
jump  of  at  least  .02  inches  in  less  than  four  minutes  occurs,  and 
is  sustained  for  at  least  20  minutes,  an  SP  is  issued  by  the 
weather  observer,  and  this  will  be  passed  on  by  the  controller. 
AV-AIVOS  calls  for  a similar  pressure  detection  algorithm  which 
will  result  in  a pressure  jump  alert  being  dispatched  by  PTIS. 

(See  "Alert  Messages"  below.) 


^In  these  discussions,  "all  aircraft"  refers  to  those  aircraft 
which  have  received  either  an  initial  arrival  or  departure  PTIS 
prior  to  the  event  occurring. 


Change  in  Visibility  and/or  Precipitation  Type  - Visibility  change 
messages  will  be  dispatched  to  all  aircraft  upon  receipt  of  an 
appropriate  SP  from  AV-AWOS.  The  visibility  change  criteria  which 
result  in  an  SP  being  issued  are  the  following: 

Prevailing  visibility  (rounded  to  reportable  values)  decreases 
to  less  than,  or  if  below,  increases  to  equal  or  exceed: 

1 . 3 miles 

2 . 2 miles 

3.  1 1/2  miles 

4 . 1 mi le 

5.  All  nationally  published  landing  minimums  applicable  to 
the  airport 

6.  Values  established  locally  because  of  their  significance 
to  local  aircraft  operations. 

With  regard  to  precipitation,  AV-AWOS  currently  calls  for  the 
capability  to  detect  precipitation,  freezing  rain,  and  hail 
(optional).  Initial  detection  of  freezing  rain  and  hail  will  re- 
sult in  an  SP  being  issued.  ETIS  will  dispatch  a visibility  pre- 
ciptation  change  message  upon  receipt  of  either  the  freezing  rain 
or  hail  SP,  or  when  precipitation  is  positively  noted  in  a normal 
observation  message  from  AV-AWOS.  As  the  sophistication  of 
precipitation  and  obstructions  to  visibility  sensors  increases, 
additional  criteria  may  be  established  for  dispatching  this  type  of 
change  message.  This  will  require  simple  ETIS  software  changes  in 
the  AP  to  implement. 

Change  in  Ceiling/Sky  Condition  - Ceiling/Sky  Condition  change 
messages  will  be  dispatched  to  all  aircraft  upon  receipt  of  an 
appropriate  SP  from  AV-AWOS.  The  ceiling  change  criteria  which  re- 
sult in  an  SP  being  issued  are  the  following: 

The  ceiling  (rounded  to  reportable  values)  forms  or  dissipates 
below,  decreases  to  less  than,  or  if  below,  increases  to  equal  or 
exceed : 
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1.  3,000  feet 

2.  1,000  feet 

3.  500  feet 

4.  All  nationally  published  landing  minimums,  applicable  to 
the  airport. 

Sky  condition  change  criteria  which  result  in  an  SP  being 
issued  and  therefore  an  ETIS  change  message,  are  the  following: 

A layer  of  clouds  or  obscuring  phenomena  aloft  is  present 
below : 

1.  1,000  feet  and  no  layer  aloft  was  reported  below  1,000 

feet  in  the  preceding  observation 

2.  The  highest  published  landing  minimum,  including  circling 
minimums,  applicable  to  the  airport  and  no  sky  cover 
aloft  was  reported  below  this  in  the  previous  observation. 

These  criteria  appear  to  be  sufficient,  at  least  for  the  time 
being,  for  use  by  ETIS  to  dispatch  ceiling  and  sky  condition 
changes.  Again,  additional  criteria,  or  smaller  change  increments, 
may  be  appropriate  and  can  easily  be  accommodated  by  the  ETIS 
software. 

Change  in  RVR  or  RVV  - The  current  procedures  for  issuing  RVR  and 
RVV  values  to  arriving  and  departing  aircraft,  according  to  the  FAA 
manual  "Air  Traffic  Control"  (7110. 65A)  are  the  following: 

a.  Issue  touchdown  RVR  or  RVV  for  the  runway  in  use  as 
follows : 

1.  When  prevailing  visibility  is  1 1/2  miles  or  less 

2.  Vifhen  RVV  is  1 1/2  miles  or  less 

3.  To  departing  aircraft  when  RVR  is  6,000  feet  or  less 

4.  By  local  control  or  final  controller  for  arriving 
aircraft  when  RVR  is  4,000  feet  or  less 

5.  By  approach  control  when  RVR  is  6,000  feet  or  less 

6.  When  the  RVV  or  RVR  indicates  that  the  visibility  is 
below  the  published  minima  for  the  particular  approach 
being  executed. 
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b.  If  installed,  issue  mid  and  rollout  RVR  information  when- 
ever the  value  of  either  is  less  than  2,000  feet  and  less 
than  touchdown  RVR. 

In  addition,  controllers  will  issue  RVR  or  RVV  updates  to  the 
aircraft  in  the  terminal  area  during  marginal  conditions  according 
to  their  own  judgment  and,  of  course,  upon  pilot  request.  The  only 
additional  criterion  in  use  is  that  an  SP  is  issued  when  RVR 
(highest  value  in  preceding  10  minutes)  passes  through  2,400  feet 
from  either  direction. 

RVR  (or  RVV)  is  critical  information  to  the  pilot  under  poor 
visibility  conditions.  Most  knowledgable  sources  will  agree  that 
providing  more  timely,  frequent,  accurate  readings  to  the  pilot, 
without  adding  to  the  controller  workload,  is  a highly  desirable 
goal.  Therefore,  it  is  apparent  that  a completely  new  set  of 
criteria  is  needed  for  automatically  dispatching  RVR  changes  to 
the  cockpit  using  data  link. 

In  the  extreme,  RVR  values  could  be  rovided  continuously  when 
below  a certain  threshold,  such  as  6,000  feet.  Actually,  the  up- 
dates would  be  at  the  RVR  sensor  system  update  rate  of  15  seconds. 
However,  this  may  have  data  link  loading  implications  and  probably 
saturates  the  cockpit  with  new  messages  that  frequently  contain 
the  same  data  as  before.  Visually  monitoring  this  data,  particu- 
larly while  on  final  approach,  is  not  desirable.  Avionics  with  a 
voiced  output  for  RVR  would  be  a potentially  attractive  alternative 
to  the  visual  display. 

But  a better  approach  would  seem  to  be  to  establish  a set,  or 
sets,  of  incremental  change  criteria  which  would  trigger  a new  RVR 
or  RVV  change  message.  These  increments  may  depend  on  the  absolute 
value  of  the  reading  (smaller  increments  as  the  RVR  or  RVV  de- 
creases), the  phase  of  flight  (smaller  when  on  final  approach), 
the  direction  of  change  (larger  for  positive  changes)  and  the  type 
of  approach  (smaller  for  precision  approaches).  As  an  option, 
perhaps,  "continuous"  readout,  as  described  earlier,  could  be 
provided  upon  pilot  request. 


3-39 


Other  factors  may  enter  into  the  establishment  of  these 
criteria,  and  no  attempt  to  finalize  them  will  be  made  here. 

It  is  important,  however,  to  make  clear  the  fact  that  the  auto- 
mated, computer-controlled  dispatch  of  RVR  and  RVV,  without  any 
action  by  the  controller,  can  be  rather  easily  implemented 
according  to  any  reasonable  set  of  criteria.  It  is  therefore 
important  to  determine  from  tlie  start  what  data  under  what  con- 
ditions are  useful  to  the  pilot,  and  design  the  software  accord- 
ingly. The  current  procedures  should  be  used  as  a starting  point 
only  for  the  design  of  a much  improved,  and  less  labor  intensive 
means  of  providing  RVR  to  the  cockpit. 

Vt-'R  Minimums  - This  message  is  automatically  dispatched  to  all 
aircraft  when  either  the  ceiling  and/or  visibility  drops  below 
VFR  minimums  (1,000  feet  and  3 miles,  respectively).  It  will  not 
be  sent  to  an  aircraft  which  is  already  on  final  approach. 

Airport  Advisories  - Airport  Advisories  are  dispatched  to  all 
aircraft  immediately  after  they  have  been  entered  into  the  FTIS 
system  by  the  controller  using  the  LPDS  d isplay/ input  terminal 
or  the  TIPS  tower  display  subsystem. 

Alert  Messages  - Alert  messages  are  dispatched  to  all  aircraft  as 
soon  as  they  are  detected.  The  criteria  for  determining  alert 
conditions  are  discussed  in  Section  3. 3. 2. 2. 7,  and  will  actually 
be  implemented  by  the  automated  weather  sensor  system  processor. 
The  alert  itself  is  therefore  an  input  to  the  LPDS  processor  which 
will  immediately  transfer  the  alert  data  to  the  RTIS  software 
within  the  AP  for  dispatch  by  data  link. 

The  question  of  how  often  an  alert  message  should  be  repeated 
over  the  data  link  must  be  addressed,  and  whether  or  not  a mes- 
sage such  as  "alert  cancelled"  is  required  when  the  conditions 
improve.  It  is  desirable  to  avoid  a proliferation  of  repeated 
alert  messages  and  cancellation  messages  saturating  the  pilot 
and  the  link.  Therefore,  some  reasonable  frequency  for  repeating 
the  alert  while  the  conditions  exist  should  be  established,  con- 
sistent with  the  characteristics  of  the  sensor  system  involved 
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(time  constant,  sampling  rate,  etc.)*  No  cancellation  message  is 
really  required,  since  the  alert  is  understood  to  be  in  effect  for 
a length  of  time  equal  to  the  repetition  period.  For  example, 
LLWSAS  has  a 7-second  sample  rate  and  uses  wind  sensors  with  filter 
time  constants  on  the  order  of  30  seconds.  Therefore,  a repeat 
interval  (and  alert  validity  time)  on  the  order  of  a minute 
would  seem  reasonable.  The  pilot  understands  that  a wind  shear 
alert  is  in  effect  for  one  minute  after  detection  unless  the  alert 
is  repeated.^  Similar  criteria  can  be  established  for  thunderstorm 
alerts  and  others. 

3. 3. 2. 3. 3 F’ilot  Request  - The  final  criterion  for  dispatch  of  an 
ETIS  message  is  receipt  of  a pilot  request.  The  ETIS  software 
assembles  a message  containing  the  requested  ETIS  data  and  dis- 
patches it  to  the  requesting  aircraft.  Updates  are  automatically 
provided  if  specified  by  the  pilot.  (See  Section  3. 3. 2. 2. 8.). 

The  primary  message  type  which  falls  within  this  category  is 
departure  ETIS.  While  it  may  be  desirable,  and  certainly  is 
possible,  to  automatically  dispatch  the  departure  ETIS,  it  does 
not  appear  that  there  is  a clear  cut  event  or  time  reference  which 
could  be  used  reliably  as  a general  criterion.  The  one  pos- 
sibility, perhaps,  would  be  to  dispatch  it  immediately  after 
acquisition  of  the  DABS  transponder.  However,  the  pilot  may  be 
busy  with  other  preflight  activities  at  this  time  and  not  be 
ready  for  ETIS.  A preferable  approach  is  for  the  pilot  to  request 
ETIS  when  he  is  ready,  just  as  he  does  today  to  obtain  ATIS.  In 
this  way,  departure  ETIS  is  obtained  when  the  pilot  is  ready  in 
a simple,  reliable  manner  which  fits  well  within  his  normal  pre- 
departure planning  activities. 


^The  LLWSAS  tower  display  remains  in  alert  status  for  about  45 
seconds  after  the  last  sample  which  exceeded  the  wind  shear 
alert  threshold.  An  audible  alarm  occurs  only  at  the  onset 
of  the  alert  condition. 


The  other  message  type  which  falls  within  this  category  is 
the  general  pilot  request  for  individual  subsets  of  the  l-TIS  data. 
As  indicated  earlier  (see  Section  3, 3. 2,2, 8),  the  detailed  designs 
of  the  pilot  request  procedure,  message  formats,  etc.,  are  not  a 
part  of  this  study.  The  ETIS  software,  however,  will  be  capable 
of  responding  to  these  requests  and  will  send  the  appropriate  data 
immediately  upon  receipt  of  the  request  message. 


3. 3. 2. 3. 4 Termination  of  ETIS  - The  first  of  three  conditions 
under  which  ETIS  is  terminated  is  immediately  following  the  air- 


craft's landing  at  the  destination  airport.  This  can  be  detected 
by  an  algorithm  which  uses  surveillance  data  (position  and 
altitude)  to  establish  a "landing  zone"  around  the  airport,  with- 
in which  an  aircraft  is  considered  on  the  ground.  The  zone 
encompasses  the  general  airport  boundaries  and  extends  perhaps  a 
100  feet  or  so  from  the  surface.  When  an  aircraft  receiving 
ETIS  services  has  passed  into  this  zone  and  has  remained  there 
for  a fixed  time  period,  ETIS  services  are  terminated.  The  time 
delay,  on  the  order  of  a minute  or  two,  is  to  guard  against 
dropping  a missed  approach.  Manual  means  for  terminating  ETIS, 
such  as  a controller  entry,  are  possible  but  have  negative  implica- 
tions with  regard  to  workload  and  are  therefore  not  recommended. 

The  departure  of  an  aircraft  from  the  airport  area  is  the 
second  condition  under  which  ETIS  is  terminated.  This  can  be 
detected  by  an  algorithm  which  establishes  a "departure  zone" 
similar  to  the  landing  zone  described  above.  Its  radius  may  be 
somewhat  larger  then  the  airport  boundary  to  insure  that  wind 
shear  alerts  are  still  provided  to  the  aircraft  as  long  as  it  is 
within  a hundred  feet  or  so  of  the  surface.  Other  ETIS  services 
which  are  useful  to  the  pilot  beyond  this  point  in  his  departure 
are  altimeter  setting  changes  and  thunderstorm  alerts.  These 
can  be  provided  by  ETIS  for  some  additional  volume  of  airspace 
around  the  airport,  but  at  some  stage  in  the  flight,  these  and 
other  message  types  must  be  taken  over  by  other  enroute  data  link 
services  such  as  weather  delivery. 


!i 

1 f 


1 

1 

I 

I ; 

The  final  event  which  leads  to  termination  of  ETIS  is  a 
request  by  the  pilot.  This  option  must  be  left  open  to  the 
pilot  who,  for  whatever  reason,  does  not  want  additional  ETIS 
messages  to  be  sent  via  data  link.  The  request  would  normally 
be  via  a downlink  message,  as  illustrated  in  Section  3. 3. 2. 2. 8, 
but  should  also  be  available  by  voice  request  to  the  controller. 

3. 3. 2. 4 Interface  with  TIPS  - The  interface  between  the  LPDS 
and  the  TIPS  tower  display  has  been  discussed  earlier.  (See  Section 
3. 3. 1.1. 4.)  However,  the  ETIS  concept  as  presented  here  assumes 
an  interface  between  the  AP  and  the  TIPS  Terminal  Flight  Data 
Processor  (TFDP)  to  obtain  certain  data  and  to  provide  ETIS 
information  for  display  in  the  TRACON  and  the  ARTEC.  While 
alternatives  can  be  identified  in  most  cases  (for  example,  much 
of  the  data  and  the  TRACON  interface  could  be  provided  through  ARTS) , 
an  interface  with  the  TIPS  TFDP  is  highly  desriable.  The  following 
is  a summary  of  the  functions  of  this  interface. 

Aircraft  Destination  - This  information  is  necessary  to  automa- 
tically dispatch  the  correct  initial  arrival  ETIS  only  to  those 
aircraft  bound  for  a particular  airport.  It  will  be  available  for  \ 

both  IFR  and  VFR  flights  from  TIPS.  An  alternative  is  to  obtain  I 

destination  from  ARTS  if  available,  and/or  request  destination  via  I 

data  link  if  unknown.  See  Sections  3. 3. 2. 2.1  and  3. 3. 2. 3.1.  j 

I 

Assigned  Runway  - For  the  case  of  multiple  active  runways  for  i 

landing,  the  runway  assigned  to  a particular  aircraft  is  informa-  | 

tion  necessary  for  the  ETIS  software  to  select  only  the  correspond-  j 

ing  RVR  and  wind  data  for  transmission  to  that  aircraft  on  final.  i 

It  also  enables  determination  of  below  minimum  conditions  for  the 
runway  of  interest  to  that  aircraft.  Assigned  runway  may  be  | 

A 

available  in  TIPS,  if  algorithms  are  developed  for  automatically  ' 

i 

carrying  out  this  function  or  if  entered  by  the  controller.  i 

Alternatives  include  sending  data  for  all  active  runways  to  all 

aircraft,  using  DABS  surveillance  data  to  distinguish  between 

runways,  or  having  the  pilot  or  controllers  enter  the  assigned 

runway  manually.  See  Section  3. 3. 2. 2. 3.  ! 
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Handoff  Between  Controllers  - There  are  two  cases  where  a handoff 
event  may  be  used  by  ETIS  as  an  alternative  to  surveillance  data; 
triggering  of  the  initial  arrival  ETIS  and  the  final  approach  data 
message.  In  both  cases,  a handoff  event  occurs  at  or  near  the 
appropriate  time,  and  these  events  are  available  from  TIPS  or  ARTS. 
See  Section  3. 3. 2. 3.1. 

Interface  With  LPDS  - As  pointed  out  earlier,  an  alternative  to  a 
direct  interface  between  the  AP  and  the  LPDS  is  through  TIPS.  The 
concept  calls  for  an  interface  at  the  local  airport  between  the 
LPDS  and  the  TIPS  tower  display  system,  which  is  in  turn  tied  to 
the  central  TIPS  terminal  flight  data  processor,  and  could  serve  as 
the  LPDS  to  AP  interface.  See  Section  3. 3. 2.1. 

Display  of  ETIS  Data  in  the  TRACON  - Access  to  ETIS  data  by  con- 
trollers in  the  TRACON  is  obtained  using  the  TIPS  TRACON  Display 
Subsystem.  The  ETIS  software  in  the  co-located  AP,  through  its 
interface  with  TIPS,  provides  the  ETIS  data  for  each  airport  within 
coverage  of  the  associated  DABS  sensor.  Display  format  and  pro- 
cedures for  accessing  the  data  must  be  incorporated  into  the  final 
TIPS  design.  The  alternative  of  a dedicated  ETIS  display  in  the 
TRACON  does  not  seem  warranted  and  is  not  recommended.  fSee 
Section  3.6.) 

Displ^  of  ETIS  Data  in  the  ARTCC  - Approach  control  for  many  re- 
mote airports  is  provided  by  the  ARTCC.  While  not  likely  to  be 
initial  candidates  for  ETIS,  eventually  some  of  these  airports  will 
be  equipped  and  will  therefore  necessitate  access  to  the  ETIS 
information  by  the  controlling  ARTCC.  TIPS  will  not  include  dis- 
plays in  the  ARTCC,  but  the  TDFP  will  interface  with  the  ARTCC 
computer  (National  Airspace  System  - NAS).  A possible  candidate 
display  is  ETABS  (Electronic  Tabular  Display  System)  which  is 
being  planned  for  implementation  in  ARTCC's  in  the  early  1980's. 

A 'dedicated  ETIS  display,  similar  to  that  used  in  non-TIPS  towers, 
can  also  be  considered,  although  this  does  not  seem  to  be  warranted. 
An  alternative  to  a TIPS  interface  is  NADIN  (National  Airspace 
Data  Interchange  Network).  In  any  case,  the  ETIS  software  in  the 
AP  must  provide  ETIS  data  for  each  airport  whose  approach  control 
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is  provided  by  that  ARTCC.  The  funtional  operation,  formats,  etc., 
of  this  display  and  that  of  the  TRACON  display  are  essentially  the 
same.  (See  Section  3.6.) 

The  ETIS  software  interface  with  TIPS  will  be  implemented 
between  the  AP  and  the  TIPS  terminal  flight  data  processor,  which 
are  likely  to  be  co-located.  Some  data  must  be  provided 
automatically  by  TIPS  (e.g.,  handoffs) , while  other  data  can  be 
provided  automatically  or  on  request  from  ETIS.  The  design  itself 
is  not  important  at  this  point,  but  it  does  seem  likely  that 
potential  data  link  services  other  than  ETIS  will  find  this 
interface  necessary  (e.g.,  clearance  delivery).  The  design  must 
take  this  into  account. 

3. 3. 2. 5 Exchange  of  Data  with  Other  APs  - Two  aspects  of  the  ETIS 
concept  depend  upon  the  exchange  of  ETIS  data  among  AP's.  The 
first  is  the  requirement  that  an  aircraft  have  access  to  any  ETIS 
data  from  any  location.  Thus  an  aircraft  200  miles  from  its 
destination  must  be  able  to  request  ETIS  for  that  location,  even 
though  it  is  well  beyond  coverage  of  the  corresponding  DABS  sensor 
(60  miles)  and  its  AP.  This  is  accomplished  by  interconnection  or 
netting  of  the  APs.  A pilot  request  for  ETIS  not  included  in  the 
ETIS  software  of  the  AP  receiving  the  request  is  forwarded  to  the 
appropriate  AP,  where  the  response  message  is  generated  and  sent 
to  the  originating  AP  for  transmission  to  the  requesting  aircraft. 

The  second  aspect  which  calls  for  netting  of  the  APs  involves 
dispatching  the  initial  arrival  ETIS  as  described  in  Section 
3. 3. 2. 3.1.  Aircraft  approaching  an  ETIS  equipped  airport  located 
near  the  boundary  of  coverage  of  the  DABS  sensor  which  includes  that 
airport  may  not  be  within  coverage  of  that  sensor  at  the  point  when 
initial  arrival  ETIS  is  to  be  dispatched.  In  this  case,  the  AP 
associated  with  the  adjacent  DABS  sensor  whose  coverage  the  aircraft 
is  under  must  obtain  the  ETIS  from  the  adjacent  AP  and  send  it  to 
the  aircraft.  Furthermore,  when  control  is  transferred  to  the  final 
DABS  sensor,  some  status  data  may  have  to  be  transferred  between 
the  AP's  to  confirm  what  ETIS  data  has  been  sent  to  the  aircraft. 


\ 
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(This  is  probably  also  true  for  data  link  functions  other  than 
F.T  IS.) 

In  this  latter  case,  all  ETIS  message  types  and  capabilities 
must  be  available  to  the  aircraft  while  under  coverage  of  either  of 
the  DABS  sensors,  including  alerts  and  below  minimums  messages. 

For  this  reason,  it  may  be  preferable  to  maintain  a complete  ETIS 
data  base  within  the  AP  for  each  airport  for  which  that  AP  may  have 
to  provide  ETIS  data  on  a routine  basis.  In  other  words,  rather 
than  an  adjacent  AP  requesting  ETIS  data,  it  would  automatically 
be  sent  a complete  ETIS  update  each  time  the  controlling  AP  polls 
the  appropriate  LPDS.  This  is  a tradeoff  which  must  be  made  when 
the  detailed  interface  design  is  carried  out.  It  is  expected  that 
the  netting  of  AP’s  will  be  accomplished  utilizing  National  Air- 
space Data  Interchange  Network  (NADIN) . 

3.4  AVIONICS 

Data  link  avionics  consist  of  displays  and  input  devices,  plus 
message  processing,  memory  and  interface  electronics  to  provide 
compatibility  with  the  DABS  transponder  and  data  link  design.  These 
avionics  will  be  shared  among  the  various  data  link  applications, 

ETIS  included,  and  their  design  will  therefore  be  influenced  by  the 
overall  data  link  concept,  of  which  ETIS  is  only  one  part.  Never- 
theless, it  is  of  interest  to  discuss  the  relationships  between  the 
ETIS  concept  and  the  data  link  avionics  design,  bearing  in  mind  that 
other  factors  must  eventually  be  considered  as  well . 

The  avionics  design  per  se  is  up  to  the  avionics  manufacturers, 
the  airlines,  ARINC,  etc.  In  discussing  avionics  design  in  the 
context  of  the  ETIS  concept,  the  intent  is  simply  to  focus  attention 
on  those  aspects  of  the  ETIS  concept  which  will  influence  that  de- 
sign and  therefore  the  human  factors,  cost,  flexibility,  reliability, 
etc.,  of  the  data  link  avionics. 

3.4.1  Range  of  Capability 

ETIS  must  be  available  to  as  large  a percentage  of  the  poten- 
tial user  population  as  possible.  This  includes  the  large  com- 
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mcrcial  jet,  the  single-engine  aircraft  in  a VFR  flight,  and 
everything  in  between.  The  data  link  avionics  which  the  com- 
mercial air  carrier  can  afford  to  install  in  his  fleet  will  have 
considerably  more  capability  than  that  of  the  average  private 
pilot.  KTIS,  and  all  data  link  applications  for  that  matter, 
should  be  designed  in  such  a way  that  the  primary  part  of  the  ser- 
vice, if  not  all,  can  be  provided  to  a minimally  equipped  aircraft. 

It  is  expected  that  some  minimum  data  link  capability  will  be 
required  for  an  aircraft  to  be  considered  DABS  data  link  equipped. 
The  DABS  data  link  design  provides  a means  for  the  avionics  to 
indicate  capability  in  its  reply  messages,  so  that  services  can  be 
tailored  as  required.  While  a minimum  capability  has  not  been 
determined,  it  is  reasonable  to  assume  it  will  require  display  of 
at  least  a short  message  (15-20  characters)  and  some  provisions 
for  pilot  input,  probably  alphanumeric  such  as  the  touch-tone 
keyset.  With  the  cost  and  availability  of  solid  state  memory  so 
attractive  now,  it  is  also  reasonable  to  assume  that  all  data 
link  avionics  will  include  some  memory  capability  so  that  the 
avionics  may  receive  and  store  messages  which  are  too  long  for  its 
limited  display.  These  avionics  must  also  include  some  means  for 
the  pilot  to  then  have  access  to  the  various  stored  message  seg- 
ments. 

At  the  other  extreme,  data  link  avionics  which  include  CRT 
displays  with  large  message  display  capabilities,  printers,  and 
highly  flexible  pilot  input  devices  have  virtually  no  limit 
(imposed  by  the  avionics  itself)  to  the  data  and  message  ex- 
changes which  can  take  place.  ETIS  should  therefore  be  designed 
so  as  not  to  restrict  unnecessarily  its  use  by  aircraft  that  are 
fully  equipped. 


3.4.2  Message  Size  and  Codinc 


The  initial  arrival  or  departure  ETIS  is  the  longest  of  any 
ETIS  message  type.  It  can  be  divided  into  two  parts,  the  normal 
data  being  one  part,  and  the  airport  advisories,  etc.  the  other. 
To  display  the  first  part  with  suitable  abbreviations,  somewhere 


on  the  order  of  100  characters  are  required  for  the  case  with 
three  active  runways.  (See  Figure  3-3.)  The  airport  and  advisories 
can  require  any  number  of  characters.  While  an  upper  limit  is 
hard  to  estimate,  200  characters  or  more  are  conceivable. 

fhe  first  part  of  the  ETIS  message  can  be  coded  rather 
easily,  perhaps  in  two  or  three  different  forms  or  types  depending 
upon  the  airport,  so  that  only  parameter  values  need  be  included 
in  the  data  link  message.  (See  Figure  3-3.)  Combined  with 
"intelligent"  avionics  which  recognizes  the  F.TIS  message  type, 
a standard  format  of  labels  can  be  applied  from  avionics  memory 
to  the  parameters  received  over  the  link  and  the  complete  message 
displayed.  Similarly,  alert  messages,  final  approach  data,  etc. 
can  be  coded  with  the  message  type  and  then  only  the  parameter 
values  transmitted.  The  avionics  would  fill  in  the  blanks,  so  to 
speak,  with  standard  text  from  memory.  Coding  of  this  type  com- 
bined with  intelligent  avionics  permits  sending  most  ETIS  data 
portions  (excluding  the  advisories)  in  three  or  four  DABS  Comm-A^ 
interrogation/reply  cycles,  with  the  worst  case  (e.g.,  three 
active  runways)  requiring  perhaps  up  to  six  Comm-A  messages.  The 
intelligent  avionics  required  here  is  reasonable  to  assume  for  the 
minimum  capability  case,  as  it  essentially  requires  prestored 
memory  capacity  the  cost  of  which  is  low  and  getting  lower  as 
indicated  earlier. 

The  second  portion  of  the  initial  arrival  ETIS  (airport 
advisories)  is  not  readily  encoded  and  must  be  transmitted  in  a 
free  text  format.  Assuming  eight  characters  can  be  handled  by  a 
Comm-A  message,  four  or  five  such  messages  are  required  for  rather 
short  advisories,  and  20-25  for  a given  ETIS  are  easy  to  envision. 
This  latter  case  is  clearly  unacceptable,  and  would  call  for  use 
of  the  extended  length  message  (ELM)  Comm-C^  capability  of  DABS. 

^Comm-A  ground-to-air  interrogations  include  56  bits  in  a data 
link  message.  Each  Comm-A  interrogation  must  be  acknowledged 
by  an  individual  reply  from  the  aircraft  transponder.  Comm-C 
interrogations  are  intended  for  more  efficient  transmission  of 
long  ground-to-air  data  link  messages.  Each  includes  an  80-bit 
message  field  and  up  to  16  Comm-C  interrogations  can  be  trans- 
mitted in  a single  burst  and  acknowledged  with  a single  trans- 
ponder reply. 
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Combining  the  two  parts  of  the  HITS  message,  about  seven 
COMM-A  messages,  and  on  up,  are  required,  assuming  encoding  of 
the  first  part.  At  some  point,  Comm-C  will  be  required,  depending 
upon  what  limit  is  established  on  successive  Comm-A  interrogation/ 
reply  cycles.  However,  the  number  four  is  currently  being  con- 
sidered for  this  limit,  which  implies  that  hTIS,  at  least  initial 
arrival  and  departure  messages,  may  require  Comm-C  capability  in 
the  avionics.  This  is  significant  because  it  is  not  intended  at 
this  time  to  require  Comm-C  capability  on  all  DABS  transponders. 
Therefore,  ETIS  could  easily  be  unavailable  to  some  significant 
share  of  the  users. 

Several  alternatives  can  be  postulated.  The  coded  first 
portion  of  the  ETIS  (and  the  most  critical)  can  be  transmitted 
first  as  a series  of  Comm-A  messages.  The  airport  advisory  portion 
can  then  be  sent  as  a Comm-A  message  or  as  separate  groups  of  four 
Comm-A;s  (or  whatever  the  limit  is).  The  first  case  measn  the  non- 
Comm-C  equipped  aircraft  will  not  get  the  advisory  portion,  and 
must  obtain  this  via  the  DVS/VHF  channel,  negating  much  of  the 
advantage  of  the  data  link  service.  The  second  case  seems  un- 
acceptable primarily  because  it  in  effect  defeats  the  purpose  of 
the  ELM  function  of  the  link,  and  has  serious  capacity  implications. 
A third  alternative  is,  of  course,  to  require  Comm-C  capability  for 
minimum  data  link  equippage,  and  send  the  ETIS  as  all  ELM.  This 
represents  the  most  efficient  and  consistent  use  of  the  link,  and 
depending  upon  the  avionics  cost  impact  and  other  implications  of 
requiring  ELM  capability,  may  be  the  best  solution.  Another 
consideration  is  what  other  data  link  services  may  also  require 
similar  ELM  capability. 

The  recommended  approach  is  a slight  variation  of  the  third 
alternative.  All  initial  arrival,  departure,  and  other  lenghty  ETIS 
messages  (e.g.  a new  advisory),  are  sent  via  Comm-C,  while  alerts 
and  the  shorter  change  messages  whose  lengths  meet  the  appropriate 
criteria  are  transmitted  as  Comm-A's.  Thus,  an  aircraft  with  a 
Comm-A/B  transponder  only  will  receive  alerts  and  critical  updates, 
but  must  obtain  initial  ETIS  over  the  DVS  broadcast.  To  receive 
full  ETIS  service,  the  transponder  must  have  Comm-C  capability  as 


well.  A pseudo- Comm- D reply  capability  is  required  for  link 
compatibility  only,  but  no  actual  downlink  ELM's  need  be  trans- 
mitted. This  enables  ETIS  (and  other  data  link  services)  to 
utilize  the  ELM  mode  (Comm-C)  while  not  requiring  avionis  to 
have  the  higher  power,  greater  cost  capability  of  transmitting  ! 

ELM's.  Receipt  of  ELM's  by  the  avionics  does  not  have  a signifi- 
cant impact  on  cost,  as  it  essentially  requires  an  increase  in  i 

memory  size,  a relatively  inexpensive  addition. 

3.4.3  Display  Size 

Figure  3-3  and  Section  3.4.2  indicate  that  even  with  coding  of 
the  ETIS  data  parameters,  and  using  intelligent  avionics,  the  dis-  | 

play  of  just  the  data  portion  of  the  initial  arrival  ETIS  requires  ■ 

a display  size  on  the  order  of  100  characters.  This  is  a con- 
siderable requirement  for  implementation  in  a low-cost,  minimum 
configuration,  although  CRT  and  printer  technologies  are  advancing 
rapidly  and  may  actually  be  quite  suitable  for  the  small  single- 
engine aircraft  in  the  mid-1980's.  Physical  size  of  the  display 
must  also  be  considered,  since  panel  space  is  limited  in  all  air- 
craft. 

Alternatives  to  displaying  all  of  the  message  at  once  are 
feasible,  requiring  only  that  the  avionics  be  able  to  receive  and 
stcre  the  entire  message  as  received  over  the  data  link.  For 
example,  each  line  of  data  in  Figure  3-3  is  16  characters  or  less 
(including  spaces).  Each  line  or  segment  of  data  could  be  called- 
up  sequentially  by  the  pilot  with  only  a 16  window  display  and  a 
message  advance  push  button.  Accessing  an  individual  segment  in 
the  middle  of  the  message  would  require  more  sophisticated  display 
controls,  but  could  be  provided.  Limiting  each  airport  advisory' 
segment  to  sixteen  characters  may  be  somewhat  of  a problem;  however, 
it  is  not  impossible. 

Another  alternative  would  have  the  ETIS  software  dispatch  only 
one  segment  of  the  message  (say  16  characters)  at  a time  and  wait 
for  a pilot  response  before  dispatching  the  next  one.  The  only 
advantage  to  this  is  elimination  of  the  memory  requirement  in  the 
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avionics,  not  a significant  factor.  The  disadvantages  are  in- 
creased complexity  on  the  ground,  increased  pilot  workload,  poor 
link  efficiency,  and  excessive  time  to  receive  the  entire  ETIS. 

This  alternative  is  not  recommended. 

For  the  better  equipped  aircraft,  a display  of  the  entire 
I-TIS  at  one  time  with  automatic  (or  pilot  option)  printing  of  it 
is  readily  achievable  and  attractive.  One  can  even  envision 
dedicated  display  windows  at  special  locations  on  the  instrument 
panel  for  key  data  such  as  altimeter  setting,  alerts,  RVR,  etc. 

An  important  point  here  is  that  the  ETIS  design,  as  well  as  that 
of  the  link  and  message  coding  must  not  limit  the  potential  flexi- 
bility and  capability  of  the  avionics  in  trying  to  accommodate  the 
minimum  configuration  user.  At  the  same  time,  while  the  minimum 
capability  user  will  pay  some  kind  of  penalty,  it  must  be  reasonable 
in  terms  of  cost/performance  tradeoffs. 

3.4.4  Message  Storage 

ETIS  messages  can  be  rather  long  and  contain  a considerable 
amount  of  data.  It  may  be  beneficial  to  the  pilot  to  be  able  to 
store  some  (or  all)  of  this  data  for  later  reference.  This  is 
certainly  true  of  other  candidate  data  link  services  such  as 
clearance  delivery. 

Two  basic  methods  of  storing  data  are  an  on-board  printer  or  a 
solid  state  memory  in  the  avionics.  A printer,  along  with  a 
volatile  display,  allows  the  pilot  to  automatically  record  all 
messages  received,  or,  at  his  option,  to  print  only  messages  he 
wishes  to  retain.  Thus,  "paper  management"  need  not  be  a problem. 

A pilot  may  also  wish  to  select  only  portions  of  an  ETIS 
message  for  printing.  This  requires  a bit  more  avionics  complexity, 
but  the  simplest  method  may  be  to  allow  line  by  line  selection  of 
those  portions  of  the  message  to  be  printed.  An  alternative  would 
utilize  the  fact  that  with  coded  data  and  intelligent  avionics, 
the  avionics  already  must  recognize  and  interpret  individual 
parameters  within  the  ETIS  data.  Simple  pilot  control  functions 
would  allow  selection  of  some  of  these  for  printing,  or  the 
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avionics  could  be  designed  to  automatically  store  only  certain 
preselected  parameters. 
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All  of  the  above  discussion  applies  essentially  to  solid  state 
memory  as  an  alternative  to  the  printer.  An  additional  considera- 
tion is  pilot  access  to  the  data.  Selective  addressing,  last  in  i 

first  out  recall,  and  scrolling  of  memory  contents  are  examples  1 

of  alternatives  that  must  be  considered.  | 

The  only  factor  in  these  discussions  which  may  be  influenced  ' 

by  the  design  of  the  data  link  and  ETIS  software  is  the  selective  . j 

storage  of  individual  data  parameters.  As  indicated  above,  auto-  j 

matic  storage  of  selected  parameters,  as  well  as  one  pilot-con-  | 

trolled  method,  depends  on  encoded  data  and  parameter  recognition  j 

by  intelligent  avionics.  The  discussion  in  Section  3.4.2  concludes  ] 

that  encoding  of  ETIS  data  will  probably  be  necessary.  This  latter 
point  is  an  additional  argument  in  support  of  that  conclusion.  , 

I 

3.4.5  Pilot  Inputs  and  Requests  i 

An  attempt  has  been  made  in  developing  this  ETIS  concept  to  | 

minimize  the  pilot  actions  required  for  obtaining  ETIS  data.  While  ; 

the  ATIS  system  now  in  use  requires  the  pilot  to  tune  to  a designated 
VHP  channel  and  listen  to  the  broadcast  information,  automatic 
transmission  of  this  information  to  the  pilot  via  data  link  is 
looked  upon  as  an  improvement  over  ATIS  (although  by  no  means  the  ! 

j 

only  improvement).  However,  certain  ETIS  functions  will  require  i 

pilot  inputs,  and  the  ETIS  design  must  therefore  take  into  account 
the  impact  on  pilot  workload  and  avionics  design. 

Required  inputs  should  be  short  and  simple.  Asking  a pilot  to 
key  in  complex,  lengthy  request  messages  is  a sure  way  to  defeat 
the  benefits  and  acceptance  of  ETIS,  or  any  other  data  link  ser- 
vice. For  example,  to  request  an  individual  ETIS  parameter,  a one 
or  two  character  code  designating  ETIS,  a three-letter  LOG  ID  code, 
plus  a single  digit  or  letter  specifying  the  parameter  desired  is 
all  that  should  be  necessary  from  the  pilot  to  obtain  that  param- 
eter . 

On  more  sophisticated  avionics,  the  ETIS  designator  may  be  a 
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dedicated  function  button  with  a "menu"  automatically  displayed 
from  which  the  pilot  selects  the  code  for  the  parameter  he  desires. 
(See  Figure  3-2.)  For  the  minimal  avionics,  the  designator  code 
may  be  entered  manually  by  alphanumeric  keys.  In  either  case,  only 
three  to  six  keystrokes  are  required,  which  is  reasonable.  Full 
alphanumeric  capability  is  required  to  take  "full  advantage  of  ETIS, 
although  the  concept  does  not  require  any  pilot  input  for  routine 
service  under  normal  circumstances.  However,  minimizing  the  re- 
quirements for  use  of  the  alphanumeric  inputs  is  an  important  goal, 
particularly  since  the  low-cost  installations  will  probably  in- 
corporate a touch-tone  type  keyset  with  two  entries  per  letter. 

For  example,  it  may  not  be  necessary  for  a pilot  requesting  ETIS 
for  his  destination  to  enter  a location  identifier  if  his  destina- 
tion is  in  the  TIPS  data  base,  and  is  "understood"  by  the  ETIS 
software . 

Another  possible  pilot  input  requirement  is  acknowledgement 
of  or  responses  to  messages  (WILCO,  UNABLE).  The  ETIS  concept 
does  not  call  for  any  such  responses  because  the  service  is 
advisory  in  nature,  and  the  technical  acknowledgement  received  by 
the  computer  verifies  that  the  correct  data  was  received  in  the 
cockpit.  "Compliance"  with  the  message  is  not  a factor  with 
advisories  such  as  ETIS,  since  the  information  is  for  the  pilot's 
benefit  in  planning  and  conducting  his  approach  or  departure. 
Furthermore,  verbal  indication  by  the  pilot  on  initial  contact 
with  the  approach  or  ground  controller  that  he  has  received  ETIS 
by  data  link  is  included  in  the  concept,  and  is  a sufficient 
"human  interchange"  of  status,  just  as  today. 

There  is  an  argument  that  for  critical  data  such  as  RVR  or 
wind  shear  alert,  it  is  necessary  that  the  controller  verify  that 
correct  data  have  been  received  by  the  pilot.  The  question  of 
controller  responsibility  enters  into  this,  but  such  arguments 
are  based  on  the  system  as  it  works  today,  and  understandably  so. 
Initial  use  of  data  link  may,  in  fact,  call  for  verbal  or  data 
link  confirmation  by  the  pilot  or  controller  of  certain  ETIS  mes- 
sages. However,  as  experience,  familiarity,  and  confidence  in 
the  data  link  are  gained,  operational  procedures  should  be  tailored 


to  take  advantage  of  the  data  link  capabilities  and  minimize  what 
can  be  agreed  upon  as  unnecessary  human  involvement. 

3.5  MESSAGE  DISPLAY  EORMATS 

The  specific  format  of  the  ETIS  messages  as  displayed  to  the 
pilot  is  a function  of  avionics  design,  since  the  assumption  is 
made  that  the  data  as  it  is  transmitted  over  the  link  will  be 
encoded.  In  other  words,  wind  can  be  displayed  as: 

WIND  FROM  240  DEGREES  AT  10  KNOTS,  OUSTING  TO  21  KNOTS 

or : 

WND  24/10/21 

or  anything  in  between  from  the  same  coded  data  received  over  the 
link.  A display  of  avionics  system  may  even  have  dedicated 
windows  or  areas  for  certain  data.  However,  it  is  useful  to  at 
least  give  some  indication  as  to  how  each  data  link  message  type 
shown  in  Table  3-2  might  be  displayed  by  the  avionics.  Table  3-3 
gives  one  example  and  an  explanation  for  each  message  type. 

3.6  CONTROLLER  DISPLAYS 

Controllers  in  the  tower,  TRACON,  and  ARTCC  must  have  access 
to  ETIS  data,  even  though  ETIS  automatically  dispatches  its  informa- 
tion over  the  DABS  data  link.  Link  or  hardware  failures  and  un- 
equipped aircraft  are  just  two  reasons  why  the  controller  must  be 
kept  informed  of  the  current  ETIS  of  interest  to  him. 

This  concept  proposes  the  use  of  the  TIPS  display  where 
available,  which  eventually  should  include  all  TRACONS  and  nearly 
all  towers.  A specific  display  is  not  proposed  for  the  ARTCC,  but 
ETABS  is  a possible  candidate.  Dedicated  displays  could  be  used 
in  any  of  these  locations,  and  may  be  required  where  TIPS  (or  some 
other  suitable  integrated  display)  is  not  available. 

The  following  paragraphs  present  several  considerations  to  be 
made  in  designing  the  ETIS  display  for  the  controller,  whether  or 
not  it  is  integrated  with  other  functions.  The  interest  here  is 
not  to  provide  a specific  design  but  to  point  out  some  of  the 


TABLE  3-3.  TYPICAL  MESSAGE  DISPLAY  FORMATS  (CONTINUED) 
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factors  which  evolve  from  the  ETIS  concept  and  must  be  taken  into 
account  in  the  actual  design. 

3.6.1  Data  Format 

The  data  must  be  presented  in  a clear,  easily  readible  form, 
and  in  such  a way  that  the  controller  can  quickly  pick  out  one 
specific  data  item  of  interest,  such  as  altimeter  setting.  While 
a highly  compressed  format,  such  as  the  standard  sequence  reports 
over  Service  A,  may  be  satisfactory,  more  easily  readable  form 
with  each  data  item  labeled  should  be  much  more  acceptable.  This 
is  particularly  appropriate  since  the  data  are  real  time  variant, 
and  not  "frozen"  for  long  periods  of  time.  Also,  a dedicated  area 
of  the  display  for  alerts,  with  appropriate  audible  warning,  should 
be  considered. 

If  TIPS  is  to  be  utilized,  some  changes  to  its  display  concept 
may  be  required.  It  currently  provides  no  display  of  ETIS  (or 
ATIS)  as  such,  and  includes  only  a single,  68  character  line  for 
weather,  which  appears  in  the  compressed,  sequence  report  format, 
and  a single  line  for  status  (advisories,  etc.).  As  a minimum,  the 
controller  should  be  able  to  request  ETIS  on  the  TIPS  display 
with  a quick  action  key,  and  receive  an  expanded  presentation  of 
all  data  with  each  item  labeled.  Alerts  would  appear  in  a designa- 
ted area  automatically  when  they  occur.  In  this  way,  no  expansion 
of  the  display  itself  is  necessary,  nor  is  elimination  or  reduction 
of  any  of  its  current  capabilities,  while  quick,  easy  access  to 
ETIS  data  is  provided. 

3.6.2  Time  of  Validity 

For  cases  of  non-DABS-equipped  aircraft  which  receive  initial 
ETIS  only  over  the  DVS,  and  do  not  receive  any  updates  (as  with 
ATIS)  , it  may  be  necessary  to  provide  some  means  for  the  controller 
to  determine  the  validity  of  the  ETIS  data  which  may  have  been 
obtained  by  the  pilot  well  in  advance  of  being  handed  over  to 
approach  control.  While  a number  of  alternatives  are  possible,  a 
straightforward  method  is  to  include  GMT  time  with  each  ETIS  message 
broadcast  by  the  DVS.  As  stated  in  Section  3.2.11,  it  is  not  clear 
that  a time  tag  is  required  for  normal  ETIS  via  data  link.)  The 
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controller  display  of  fc'TIS  would  then  include  a "validity  time," 
which  is  the  oldest  GMT  time  for  which  the  ETIS  data  are  still 
valid . 


This  validity  is  the  function  of  the  changes  occurring  in  the 
data,  and  depends  on  the  rate  and  magnitude  of  the  changes.  For 
example,  any  change  message  (such  as  altimeter  setting,  visibility, 
etc.)  will  result  in  the  validity  time  being  increased  to  the  time 
of  the  change  message.  Similarly,  any  alert  or  a new  airport 
advisory  etc.,  results  in  a revised  validity  time.  Other  changes 
in  the  data  of  a less  critical  nature  will  not  immediately  affect 
the  validity  time.  Small  fluctuations  in  temperature  or  wind,  for 
example,  will  not  change  the  validity  time,  while  slow,  gradual 
trends  will,  once  a significant  increment  has  been  accumulated. 

The  overall  consideration  is  that  the  validity  time  remain  constant 
as  long  as  it  provides  an  accurate  representation  of  the  terminal 
conditions . 

When  validity  time  changes,  an  indication  of  some  type 
should  be  provided  to  the  controller,  including  which  data  have 
changed.  The  controller  can  then  provide  this  new  data  to  any 
non-DABS-equipped  aircraft  under  his  control.-  In  this  way,  there 
is  no  need  to  provide  a complete  new  ETIS  report  to  these  aircraft, 
only  the  parameter  that  has  changed,  and  the  controller  is  given 
a specific  indication  as  to  when  the  change  is  significant  enough 
that  an  update  should  be  given. 

The  algorithms  for  controlling  validity  time  can  reside  in 
either  the  LPDS  processor  or  the  ETIS  software  in  the  AP.  However, 
in  order  to  preserve  the  stand-alone  feature  of  the  LPDS,  the  i 

algorithms  will  have  to  be  included  as  a function  of  the  LPDS 
processor.  The  validity  time  then  also  becomes  a part  of  the 
ETIS  data  transmitted  to  the  AP. 
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3.6.3  Message  Delivery  Status 


A means  must  be  provided  to  inform  the  controller  of  an  un- 
successful attempt  by  DABS  to  send  an  ETIS  message  to  an  aircraft. 
Because  ETIS  messages  are  advisory  in  nature  and  are  normally  dis- 
patched automatically  without  any  controller  action,  there  is  no 
general  requirement  that  he  review  each  one  prior  to  its  being 
transmitted,  such  as  is  likely  to  be  the  case  for  ATC  messages 
(vectors)  altitude  assignments,  etc.)  Furthermore,  with  no  WILCO 
response  to  ETIS  messages  required,  the  controller  has  no  pilot 
feedback  to  indicate  successful  delivery  of  messages.  Thus,  he 
has  no  continuous  display  of  ETIS  message  delivery  status  for  each 
aircraft,  nor  does  he  require  such  a display.  But  when  a message 
fails  to  be  delivered,  for  whatever  reason,  the  controller  must 
then  be  informed  of  the  exact  situation. 

Some  general  indication  to  initially  get  the  controller's 
attention  can  be  used,  such  as  a flashing  data  block  on  the  radar 
display  or  special  symbology  added  to  the  data  block.  This 
alerts  the  controller  to  check  the  ETIS  display  (TIPS) , where  it 
is  proposed  that  the  specific  message  and  aircraft  ID  preempt 
a portion  of  the  normal  display.  After  giving  the  message  by 
voice,  use  of  the  quick  action  keys  allows  the  controller  to 
return  the  display  to  its  normal  state. 

An  audible  alert  as  a general  indication  to  the  controller 
of  the  problem  may  be  more  suitable  than  adding  to  the  clutter  of 
the  radar  screen.  This  is  also  preferable  in  the  tower  where 
the  controller  is  not  usually  watching  a radar  display.  The 
audible  alert  could  be  accompanied  by  flashing  the  appropriate 
portion  of  the  TIPS  display.  Or,  the  alert  itself  could  be  a 
stored  voice  message  such  as  "Check  ETIS." 

3.6.4  Other  Controller  Display  Considerations 

Several  other  controller  display  design  considerations  of  a 
more  general  nature  are  summarized  below.  These  apply  primarily 
to  data  link  services  other  than  ETIS,  but  it  is  useful  to  mention 
them  here. 


1.  Some  type  of  character  or  symbol  should  be  included 
in  the  data  block  of  all  aircraft  that  are  data  link 
equipped.  Two  or  more  characters  may  be  required  to 
differentiate  between  levels  of  avionics  capability. 
Alternatively,  this  information  could  be  included  in 
tabular  form  in  a designated  area  of  the  radar  screen. 

2.  Messages  which  must  be  reviewed,  approved,  and/or  actively 
dispatched  by  the  controller  must  be  displayed  to  him  in 
some  form,  probably  on  the  radar  screen.  (ETIS  as  cur- 
rently conceived  does  not  include  messages  of  this  type.) 
An  indication  that  the  message  was  received  and  properly 
acknowledged  must  also  be  provided,  perhaps  with  the 
addition  of  a symbol  for  a fixed  time  period  and  then 
deletion  of  the  message.  In  the  event  of  a problem  in 
delivering  these  messages,  a suitable  means  for  alerting 
the  controller  must  be  implementer . (See  Section  3.6.3.) 

3.  If  a pilot  cannot  comply  with  a message  he  has  received 

by  data  link,  or  has  some  question  regarding  it,  some  type 
of  response  on  his  part  to  so  indicate  is  required.  This 
may  simply  be  picking  up  the  microphone  and  establishing 
voice  contact  with  the  controller.  Or,  particularly  as 
more  communications  are  handled  by  data  link,  an  "Unable" 
type  response  (as  opposed  to  WILCO)  may  be  utilized  over 
the  data  link  under  these  circumstances.  If  this  is  the 
case,  an  indication  of  the  Unable  response  must  be  given 
to  the  controller  so  that  he  may  take  the  appropriate 
action.  The  addition  of  a specific  symbol  to  the  data 
block  or  to  the  message  receiving  the  Unable  response, 
and  perhaps  flashing  of  the  data  block  or  the  message  to 
quickly  get  the  controller's  attention,  is  one  possible 
method  of  handling  this  situation. 
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^1.  TYPICAL  ETIS  SCENARIOS 


The  following  paragraphs  describe  several  typical  scenarios 
involving  the  use  of  ETIS  by  pilots  conducting  IFR  and  VFR  flights 
with  different  levels  of  avionics  capability.  While  all  possible 
combinations  of  circumstances  and  events  can  not  be  included,  a 
representative  sample  should  be  sufficient  to  help  in  fully  under- 
standing the  DABS  ETIS  concept. 

Note  that  in  the  following  scenarios,  other  data  link  services 
will  be  available  and  in  use  by  these  aircraft.  Only  the  ETIS 
services  will  be  described,  however,  as  the  others  are  beyond  the 
scope  of  this  study,  and  are  not  fully  documented  at  this  time. 

4.1  FULL  CAPABILITY  AVIONICS,  IFR 

This  example  is  representative  of  the  commercial  airline 
installation  as  well  as  the  business  jet  and  perhaps  some  of  the 
larger  commuter  airline  twins.  The  flight  is  under  instrument 
flight  rules,  there  are  two  or  more  crew  members  on  board,  and 
the  data  link  avionics  and  DABS  transponder  include  ELM  capability, 
printer,  CRT,  and  extensive  function  button/pilot  input  capability. 

Departure  is  from  a major  airport  with  a co-located  DABS  sen- 
sor and  coverage  is  available  over  the  airport  surface.  Early  in 
the  pre-flight  preparation,  the  DABS  avionics  is  turned  on  and 
is  acquired  by  the  DABS  sensor.  A crew  member  presses  a single 
function  button  marked  "ETIS,"  then  a send  button.  The  following 
message  appears  on  the  CRT:^ 

ETIS  BOS  1413 

SKY  55S/85S 

VSB  6 

WND  18/7/0 

^ince  the  aircraft  is  on  the  ground,  it  is  understood  departure 
ETIS  is  desired,  and  no  LOC  ID  is  necessary. 
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TMP  58/42 

ALT  2999 

DLP  27 

APR  22L/22R 

CLNC  DELY  119.0 

CAUTN  BIRDS  RPTD  OFF  R27. 

The  crew  member  notes  that  the  message  has  been  automatically 
printed,  as  are  all  messages  under  company  policy  for  this  particu- 
lar airline.  The  flight  receives  its  clearance  and  starts  taxiing 
out  when  a data  link  message  appears  on  the  CRT: 

BOS  ALT  2998. 

The  crew  sets  in  the  new  reading  and  the  flight  departs  routinely. 

The  flight  proceeds  with  no  further  ETIS  messages  until  it 
nears  its  destination,  where  conditions  are  poor,  and  RVR  is  near 
minimums.  About  40  miles  out  from  the  airport,  shortly  before 
being  handed  off  to  approach  control,  the  following  message  is 
automatically  sent  to  the  aircraft: 

ETIS  MIA  1747 

SKY  04B 

VSB  1/2+R 

WND  04/3/0 

TMP  81/81 

ALT  2980 

APR  ILS  6/RVR  20 
DEP  32  . 

The  crew  reviews  the  ILS  runway  6 approach  procedures,  and  the 
flight  is  handed  off  to  approach.  Upon  contacting  approach 
control,  the  pilot  indicates  he  has  data  link  ETIS. 
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While  the  flight  is  being  vectored  for  the  approach,  the 
following  message  is  received: 

MIA  1802 

R6  RVR  19/19/18. 

Because  this  is  below  minimums  for  the  approach,  the  pilot  is  in- 
structed by  the  controller  to  proceed  to  the  outer  marker  and  hold. 
Before  reaching  the  outer  marker,  the  pilot  wishes  to  verify  that 
the  RVR  is  still  below  minimums.  He  presses  a function  button 
labeled  "RVR"  and  the  send  button,  and  receives  the  following: 

MIA  1809 

R6  RVR  19/18/18. 

The  pilot  enters  the  holding  pattern  at  the  outer  marker  and  re- 
ceives periodic  RVR  updates  automatically.  The  conditions  begin 
to  improve  and  when  RVR  reaches  minimums,  the  flight  is  cleared 
for  the  approach.  After  departing  the  holding  pattern  and  while 
passing  the  outer  marker  inbound,  the  following  message  is  received 
by  the  aircraft: 

CF  WND  08/5/0 
R6  WND  07/7/0 
RVR  21/21/20. 

The  flight  makes  a routine  landing  and  taxies  to  the  gate. 

4.2  MODERATE  CAPABILITY  AVIONICS,  IFR 

This  second  example  is  representative  of  a wel 1 - equipped  light 
twin,  perhaps  for  business  or  small  commuter  airline  use.  The 
flight  is  IFR  and  the  aircraft  is  equipped  with  an  ELM  capability 
DABS  transponder,  display  integrated  with  the  weather  radar  CRT, 
and  a full  alphanumeric  keyboard  with  some  dedicated  function 
buttons . 

The  airport  of  departure  is  ETIS  equipped  but  is  remote 
from  the  DABS  sensor  so  that  no  coverage  exists  at  the  surface. 
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The  pilot  tunes  to  the  appropriate  VHP  frequency  (formerly  used 
for  ATIS  at  this  airport)  and  receives  the  following  broadcast  from 
the  local  VRS: 

"Springfield  Municipal  automated  ETIS  information  at  one  four 
two  two  Greenwich.  Sky:  three  two  hundred  scattered,  four 
eight  hundred  broken.  Visibility:  four  miles  in  light  snow. 
Wind:  two  five  "ero  degrees  at  one  one.  Temperature:  four 

eight.  Dewpoint:  three  seven.  Altimeter:  two  niner  niner 
one.  Localizer  two  eight  approach  in  use.  Departures  on 
runway  two  eight.  Glide-slope  runway  two  eight  out  of 
service.  Advise  you  have  ETIS  information  one  four  two 
two . " 

He  receives  his  clearance,  taxies  out,  and  departs  the  airport  on 
his  I PR  flight  plan . 

While  still  a hundred  miles  or  so  from  his  destination,  the 
pilot  decides  to  take  advantage  of  the  relatively  low  workload 
during  that  time  and  begins  to  plan  his  arrival.  He  requests 
ETIS  for  his  destination,  pressing  a function  button  labeled 
"Pilot  Request,"  a menu  list  of  downlink  request  messages  appears 
on  the  CRT.  The  pilot  selects  #3,  which  corresponds  to  ETIS,  by 
pressing  the  #3  numeric  input  button,  and  then  presses  the  "Send" 
button.  The  request  is  received  on  the  ground,  understood  to  be 
an  ETIS  request  for  the  destination  airport,  and  the  appropriate 
arrival  ETIS  is  transmitted  to  the  aircraft  similar  to  the  pre- 
vious example. 

As  the  aircraft  nears  the  terminal  area  and  is  handed  off 
to  approach  control,  no  repeat  of  the  ETIS  will  be  sent  to  it. 
However,  any  change  messages  will  be  sent  as  conditions  dictate 
after  the  time  the  initial  ETIS  was  sent.  Shortly  after  handoff 
to  approach,  the  following  message  is  received  by  the  aircraft: 

' I 

STL  2415 

i 

ALERT-THDRSTM 

14W/E/8. 
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After  a few  minutes,  another  message  is  received  by  the  aircraft: 


STL  2418 
ALERT -WND  SHR 
R14L  WIND  20/4/0 
CF  WND  15/24/30 
DIFF  14/21. 

Prior  to  beginning  his  final  approach,  the  following  message  is 
sent : 

STL  2427 
ALERT-THDRSTM 
12W/E/9  . 

The  pilot  elects  to  continue  the  approach,  since  he  estimates  he 
will  be  on  the  ground  well  before  the  storm  reaches  the  airport, 
based  on  the  data  he  has  received.  The  wind  shear  alert  is  of 
some  concern,  but  he  does  not  expect  it  to  be  a problem.  As  the 
aircraft  passes  the  outer  marker,  the  following  message  is 
received : 

CF  WND  16/20/30 
R14L  WND  19/8/0. 

He  continues  the  approach  and  makes  an  uneventful  landing. 

4.3  MINIMUM  CAPABILITY  AVIONICS,  VFR 

The  final  example  represents  the  pilot  flying  a small  single- 
engine aircraft  with  limited  avionics.  He  is  flying  VFR,  the 
DABS  transponder  on  board  has  Comm-A/B/C  capability  and  the  aircraft 
is  equipped  with  minimum  data  link  avionics.  The  latter  consists 
of  a sixteen  character  solid-state  display  and  a very  limited 
keyset  with  touch-tone  style  alphanumer ics  and  no  function 
buttons . 

The  aircraft  departs  from  a small,  uncontrolled  airport  that 
has  no  ETIS,  and  heads  for  a busy  general  aviation  field  several 
hours  away.  No  flight  plan  is  filed.  As  the  flight  nears  its 
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destination,  the  pilot  requests  ETIS  in  the  following  manner: 

He  pushes  the  alphanumeric  keys  which  correspond  to  the  letters 
E and  T,  which  is  the  abbreviation  for  ETIS  utilized  by  the 
avionics,  following  each  one  with  the  left,  center,  or  right  key 
to  select  the  letter.  The  sequence  is  3(DEF),  Center,  8(TUV), 
and  Left,  a total  of  four  keystrokes.  The  letters  "ET"  appear 
in  the  data  link  display.  The  pilot  follows  this  by  keying  in  the 
LOC  ID  of  his  destination,  HPN,  in  a similar  fashion.  The  sequence 
is  4(GHI)  Center,  7(PRS),  Left,  6(MN0),  and  Center.  The  final 
selection  is  the  number  1,  which  the  pilot  remembers  as  the  Code  to 
select  a full  ETIS  report.  A total  of  twelve  keystrokes  are  re- 
quired, including  the  final  "Send"  button. 

The  complete  ETIS  message  is  sent  to  the  aircraft  and  stored 
in  the  avionics.  Since  the  display  is  limited  to  16  characters, 
only  a portion  of  the  message  is  displayed  at  one  time.  An 
indicator  on  the  display  tells  the  pilot  there  is  more  of  the  mes- 
sage in  storage  which  he  accesses  by  pushing  a button  labeled 
"MSG  ADV"  (message  advance).  The  message  is  displayed  in  the 
following  sequence: 


(MSG  ADV) 
(MSG  ADV) 
(MSG  ADV) 
(MSG  ADV) 
(MSG  ADV) 
(MSG  ADV) 
(MSG  ADV) 


ETIS  HPN  1114 
SKY  4SS/850C 
VSB  3 

WND  11/09/0 
TEMP  39/27 
ALT  2986 

APR  IL09R 

DEP  09R 
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(MSG  ADV) 
(MSG  ADV) 
(MSG  ADV) 
(MSG  ADV) 


ICE  RWYS  TXWYS 

SNW  BNKS  R09R 

VFR  AC  CTC  APRCH 

124.35. 


Thus,  the  message  has  been  presented  in  12  segments,  each  one 
reviewed  by  the  pilot  prior  to  advancing  to  the  next.  These 
avionics  allow  the  pilot  to  store  up  to  ten  message  segments  by 
simply  pressing  a "STORE"  button  before  advancing  to  the  next 
segment . 

The  pilot  contacts  approach  on  the  frequency  indicated  and 
is  sequenced  into  the  arrival  flow.  About  six  miles  out,  the 
following  message  appears  on  the  aircraft  display: 


(MSG  ADV) 


HPN  1130  BLO  VFR 


VSB  2.5  CLG  85. 


The  pilot,  not  instrument  rated,  obtains  special  VFR  clearance 
from  ATC  and  continues  his  visual  approach.  Near  the  outer  marker 
of  runway  09R,  he  receives  the  following  message: 

CF  WND  11/07/0 

(MSG  ADV) 

R09R  WND  10/06/0  . 

The  pilot  continues  his  approach  and  lands  at  the  airport. 
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